Normalize line endings

[AArnott]

This git repo uses LF line endings in committed trees. But the prior .gitattributes setting told git to never regard any file as text so line endings would not be normalized. The result: depending on the configuration and/or OS of the git clone, line endings could be changed and an entire text file could appear changed in a PR, causing merge conflicts.

With this change, git will detect text files and normalize their line endings to LF to avoid this problem.

[ygoe]

This comes from other projects I'm working on. Git has the tendency to detect things and change bytes as it wants. I don't trust such heuristics very much. As a default I'm simply disabling all such automatics to have control over the file format. This is even required when having Linux shell scripts in a repository because they simply won't work with Windows line endings. And the .gitattributes file tells every client how to handle this. I simply expect everybody to use a decent text/code editor (unlike Windows Notepad for the longest time).

I guess it's not really necessary in this repo though as there are only uncritical file types.

[AArnott]

It sounds like you want LF line endings in all cases. Git isn't helping you maintain this policy at present because you've told it to leave line endings alone. My PR tells git to checkout line endings consistent with the global git settings (which typically mean CRLF on Windows and LF on Linux). But if you want it to always be LF for text files, we can amend my PR to add eol=lf so that git always checks out LF line endings. I do this at least for file types that must be recognized as linux shell scripts for the same reasons you gave. However I didn't see any shell scripts in your repo, so I left this part off.

FWIW, I sent this change because another PR I was preparing for your repo, using linux ended up committing CRLF line endings for some reason. That led to a huge whole-file diff since the line endings changed. So this PR is intended to make sure you always get the LF line endings committed that you want.

[ygoe]

Oh, I can't remember that I ever wanted to have all-LF in general. I just remember I needed it for some files (that had no extension so couldn't be addressed like that) in another project. And I do want to avoid such mess, that's correct. I've seen such mess being created because of automatic and local settings. I have a bit of a distrust in things like encoding guess-detection. So I probably said, let's not change line endings during transit but keep whatever was set in the editor. I'm not sure what set it to LF in this case. But we can try to use automatic settings in this repo and see how it goes.

In case the .gitattributes are changed, should the other files be converted then, too, to have them match the automatic's expectations?

[AArnott]

In case the .gitattributes are changed, should the other files be converted then, too, to have them match the automatic's expectations?

Good question. I just checked and it turns out that all your files are currently checked in with CRLF line endings except your package.json file. As none of these files are processed by tools that care which line endings you use, you could standardize on this and force all text files to be checked out with CRLF line endings if you want, or you could allow the OS convention to determine how they are checked out. Neither one would be problematic. But setting any standard (aside from leaving it strictly alone) means that LF line endings will be in the git index, and that represents a change to the repo. I can make that change, and I can explicitly set the commit author to you so you still get "blamed" for every line in this repo as you probably are at present.

So the question may be just this: Do you want to always have LF, CRLF, or OS-dependent line endings when your repo is checked out?