Late to this but perhaps an alternative take on this might help.
Premise
It's useful to wrap lines at a defined length...
- It fits into most buffers for users screen resolution/settings.
- It makes it easier to find errors in what would otherwise be long lines. This is my main preference for having lines hard-wrapped.
Problem
My problem is that a small wording change may trigger auto-fill to reformat a whole paragraph, and that doesn't play well with version controlling, i.e., git.
I can't track my small changes anymore, because the whole paragraph is changed.
For Git at least there is something that can help although it requires discipline and may not be perfect.
Git allows you to ignore particular revisions when viewing git blame by adding commit hashes to a specific (configurable) file the default is .git-blame-ignore-revs. I won't reproduce what I've written elsewhere and instead point to an article I wrote on how to do this...Who's to blame.
This is /really/ useful when dealing with legacy code.
Great for linting legacy code, but how to ignore small changes?
Its not that useful though for the situation described as typically it is /changes/ that alter code/text and we you /want/ to incorporate the changes but ignore the code breaks when making meaningful changes rather than just linting existing code as described above.
I don't know of a way around this in the Git version control itself, after all, adjusting carriage returns in a set of contiguous rows is the same in terms of version control as adding text to a line, both are changes.
Gut there is a way of handling this visually when viewing the differences via the say git diff which is to leverage the parameter/settings for color-moved-ws.
There are a few options available, probably ignore-space-space would be most appropriate here, it ignores changes in whitespace at end of lines, but considers all other white space to be equivalent. The caveat is that you then have to make sure you don't put any double-spaces in anywhere. ;-)
But as a consequence you get slightly different colours when doing git diff locally and perhaps on your choice of Forge too (I think Git{Hub,Lab} both do this not sure about Codeberg/SourceHut).
