I'm dealing with LF/CRLF issues in a git repository and reading git's documentation to try to understand what I need to do.

One part of the documentation is confusing to me: they write here:

...many editors on Windows silently replace existing LF-style line endings with CRLF, or insert both line-ending characters when the user hits the enter key. Git can handle this by auto-converting CRLF line endings into LF when you add a file to the index, and vice versa when it checks out code onto your filesystem. You can turn on this functionality with the core.autocrlf setting. If you’re on a Windows machine, set it to true — this converts LF endings into CRLF when you check out code.

What I don't understand is: if I'm using Windows, why would I care to convert line endings from LF to CRLF? Would it be because my editor doesn't recognize LF line endings and thus shows all the code in a file as being one line? If it's that, then it seems that if I'm using an editor that does recognize such LF line endings and shows the code correctly even when the file is using LF line endings, then I wouldn't need to do the LF-to-CRLF conversion, right?

CodePudding user response：

If your editor supports LF and you don't care about other people that might want to contribute to your repository then yes, for the most part, you don't need the conversion.

Any decent code editor from the last 20 years should handle LF files. Notepad on the other hand only supported CRLF for a very long time. Fixed in Windows 10 1809.

There still might be some command line tools that choke on LF and perhaps the biggest issue; command line tools that fopen files in text mode using the Microsoft C run-time will output CRLF even when \n is used in their code.

In the end I suppose it is a matter of preference and where you want potential conversion errors to occur; in the git auto-conversion or in tools used to parse/process the files.