Normalize line endings as LF or CRLF and encode choice in .gitattributes file

[ahelwer]

Normalize line endings as LF or CRLF and encode choice in .gitattributes file

[lemmy]

Based on the execution statistics, unix-based platforms are way more popular.

[kape1395]

I like this idea. And I'm for the Linux-style EOLs.

[lemmy]

Can we incrementally change all existing CRLF line endings to LF using a .gitattributes file, so that only the portions of a file modified by a commit have their line endings altered? Converting all CRLFs to LFs in a single operation would make comparing file versions to identify regressions very difficult.

[ahelwer]

I don't know, I think it would be better to get it out of the way in one large commit just called "Normalize line endings" so people know to ignore that one. If it's mixed in with another commit changing the file it can make it harder to see the actual change.

[lemmy]

I'm strongly against one large commit as one who relies on git diff to e.g. diagnose regressions. Related, see @Calvin-L's "Code formatting improvements - NO (er, not all at once)" in #756 (comment).

[ahelwer]

Documenting this to add to the confusion, some files have both LF and CRLF line endings within the same file. For example, this section:

https://github.com/tlaplus/tlaplus/blob/de0c1811f291fcb68e81873af1fba7eb3fa9814a/tlatools/org.lamport.tlatools/src/tla2sany/parser/TLAplusParserTokenManager.java#L4267:L4278

has LF line endings while (most of) the rest of the file is CRLF. You can see this by opening the file with vim -b filename; lines ending with CRLF will have a ^M character displayed.

This is unfortunate because I'm trying to see what modifications have been made to the javacc-generated parser code but these line endings are confounding the diff attempt. Not too much of an issue, just ran the relevant files through unix2dos and committed them on my branch first.