You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently have an attribute setting * text eol=lf in our .gitattributes file for this repository. I don't know exactly what it does, but it seems to convert CRLF-line endings to LF line endings upon commits. While this seems to be clever, as it implicitly "fixes" wrong Windows-line endings, it makes checksum-validation inconsistent between platforms.
If I locally commit a file with CRLF-endings and compute checksums, those checksums will not validate anymore on another user's platform if they have intermittently pulled my changes through git. This inconsistency is rather puzzling and surprising. I would suggest to remove this setting and accept "wrong" CRLF-line endings via git, and move the responsibility downstream to committing users, for example by adding a feature to `validate´ to check for line-endings.
The text was updated successfully, but these errors were encountered:
We currently have an attribute setting
* text eol=lf
in our.gitattributes
file for this repository. I don't know exactly what it does, but it seems to convert CRLF-line endings to LF line endings upon commits. While this seems to be clever, as it implicitly "fixes" wrong Windows-line endings, it makes checksum-validation inconsistent between platforms.If I locally commit a file with CRLF-endings and compute checksums, those checksums will not validate anymore on another user's platform if they have intermittently pulled my changes through git. This inconsistency is rather puzzling and surprising. I would suggest to remove this setting and accept "wrong" CRLF-line endings via git, and move the responsibility downstream to committing users, for example by adding a feature to `validate´ to check for line-endings.
The text was updated successfully, but these errors were encountered: