CRLF vs. LF: Normalizing Line Endings in Git

[AleksandrHovhannisyan]

[ekortright]

Very useful. Thank you.

[chriswayg]

Cool about the history. I still used teletypewriters with a dial up phone modem in a computer lab.

[SKSSSX]

For an engineer, this rivet is very important, without it, you can't build a building

[DhrumilDave5]

Thank You so much, I like articles like this where there is details like the historical ones.

[gregorybleiker]

You just saved me a lot of time, thank you!

[ahmafi]

Thanks for the great article. In * text=auto eol=lf doesn't the text=auto get ignored? Because setting eol=lf treats all files as text. I was getting confused on this and asked this question here as well.

[AleksandrHovhannisyan]

@ahmafi Oh, interesting—I think you may be right! It looks like text=auto tells Git to use its file-type detection algorithm to apply LF to text files, so eol=lf is redundant. Let me play around with this a bit more, and then I'll update the post to clarify it a bit better.

[djnotes]

Nice article, easy to understand and apply, and a bit too long :(

[germanfrelo]

Nice article, very interesting and useful. Thank you!

[Jeff-Hugh]

Very useful. Thanks a lot!

[denislutz]

You made my day, thank you! Finally a solution for this. Красава!

[KrashLeviathan]

Thanks for writing this article -- I especially appreciated the sections about verifying line endings after the change and then updating the files in your working tree. That's when everything finally clicked for me. :-)

[netzpace]

Your writing style is clear an comprehensive. Just what I was looking for. Appreciate your hard work.

[jelischer]

unfortunately Git line endings doesn't help with one scenario:

You are mirroring $hugecompanythatmakesprocessors". The developers in that company mixed CRLF and LF at some times in the past and have not cleaned it up. In order to be able to make sensible merges and diffs, you need the file in the repo to each remain in their original form, while being able to have the files checked out in your local form, and then reconverted back to the original form when checked back in. The only answer is to freeze the whole repo and use an editor that knows what it is doing and follows the original style for that file. Git unfortunately can't help you (though it could). Mix in that some of your subcontractors are working in a windows shop..

[krzychb]

Fantastic and exceptionally comprehensive article. Thank you!

[lundgrenmattias]

Very useful. Thank you!

[hyzyla]

Thanks for the article, it was interesting to read

[paddy-r]

Extremely useful, @AleksandrHovhannisyan, thanks! Combined with some specific stuff from the docs here, could fix my issue.

[markmaker]

Very useful, but all such guides seem to be missing the merge.renormalize configuration variable, which makes renormalizing the standard for all "mergy" operations like merge and cherry-pick.

See here: https://git-scm.com/docs/gitattributes#_merging_branches_with_differing_checkincheckout_attributes

Unfortunately, so far I have not found a way to make it into a .gitattributes entry, or something, so it will be particular to a branch, and centralized/mandatory for all repo clones.

[dbnex14]

Thank you for such a great article about .gitattributes at https://www.aleksandrhovhannisyan.com/blog/crlf-vs-lf-normalizing-line-endings-in-git/ it is best and most informative article I have red on tis topic Much appreciated