.braids.json written with LF line endings under Windows, causing intermittent warning

[mattmccutchen]

On Windows, Braid writes .braids.json with LF line endings. Using Git for Windows with the recommended settings (core.autocrlf = true and core.safecrlf = warn), this produces a warning on git add:

warning: LF will be replaced by CRLF in .braids.json.
The file will have its original line endings in your working directory.

This often goes unnoticed because when Braid calls git add, it swallows the warning (arguably poor design). However, depending on how quickly Braid runs, the index entry for .braids.json may be left "racily clean", in which case the next git add command will print the warning again. This appears to be the cause of the intermittent warnings when I run the test suite on Windows.

Arguably git should be enhanced so that "racily clean" entries do not lead to intermittent duplicate safecrlf warnings (edit: thread). But I'd also argue that we should consider fixing the root cause by changing Braid to write the file with CRLF endings, at least if core.autocrlf = true.

We could look to the .gitmodules file for precedent. Interestingly, git submodule add also writes it with LF endings under Git for Windows and shows a warning. I inquired about this on the Git for Windows discussion group.

[tboegi]

Using Git for Windows with the recommended settings
(core.autocrlf = true and core.safecrlf = warn)
Out of curiosity: From where did you get this information ?

My recommended handling in Windows (since some years) is to set up a .gitattributes file.

• text=auto
  *.json text eol=lf

[mattmccutchen]

Out of curiosity: From where did you get this information ?

core.autocrlf = true: "For cross-platfrom development, this is the recommended setting on Windows development workstations" (source). core.safecrlf = warn is just the git default, not a specifically recommended setting, I suppose.

My recommended handling in Windows (since some years) is to set up a .gitattributes file.

Is there a philosophical reason why JSON files should be treated differently from other text files? If not, then while this certainly works as a workaround for the current Braid behavior, it doesn't justify Braid's behavior.