CRLF vs. LF: Normalizing Line Endings in Git about aleksandrhovhannisyan.com HOT 20 OPEN

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. :-)

from aleksandrhovhannisyan.com.

Very useful. Thank you.

from aleksandrhovhannisyan.com.

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

from aleksandrhovhannisyan.com.

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

from aleksandrhovhannisyan.com.

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

from aleksandrhovhannisyan.com.

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

from aleksandrhovhannisyan.com.

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.

from aleksandrhovhannisyan.com.

@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.

from aleksandrhovhannisyan.com.

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

from aleksandrhovhannisyan.com.

Nice article, very interesting and useful. Thank you!

from aleksandrhovhannisyan.com.

Very useful. Thanks a lot!

from aleksandrhovhannisyan.com.

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

from aleksandrhovhannisyan.com.

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

from aleksandrhovhannisyan.com.

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..

from aleksandrhovhannisyan.com.

Fantastic and exceptionally comprehensive article. Thank you!

from aleksandrhovhannisyan.com.

Very useful. Thank you!

from aleksandrhovhannisyan.com.

Thanks for the article, it was interesting to read

from aleksandrhovhannisyan.com.

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

from aleksandrhovhannisyan.com.

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.

from aleksandrhovhannisyan.com.

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

from aleksandrhovhannisyan.com.