This problem arises with Git when team members are using different operating systems, e.g., Windows vs Mac/Linux.
A non-AI-generated summary of the solution:
Step 1. Decide whether to save changes in the Git index (the Git commit database) in CRLF or LF. Git wants to save in LF. The world wants to save in LF. Linux and Mac have the default of LF. Windows is alone in having CRLF. So the decision is made: LF.
Step 2. In git-config, core.autocrlf=input means when generating files from Git index for the user, Git will do CRLF for Windows and LF for Mac/Unix. Also, while writing to Git index from files, it will use LF. Having core.autocrlf=false means Git won't do anything. Just save stuff as is. So, make sure you don't change the default setting.
Another case to be aware of is that code formatters like Prettier may format the code and save the file with LF as line-endings in Windows, although the file had CRLF. In this case, Git will notice it and show a warning. Safely ignore this warning, not important at all, forget it.
warning: LF will be replaced by CRLF in <filename>.
Step 3. Usually, that's all. But some teammates might add an ESLint (or similar code formatter) rule to have all line-endings as LF.
This is tricky because tools like ESLint check the current file buffer and informs you of warnings and errors on the fly. And, in Windows, Visual Studio Code defaults to saving files with CRLF.
Now, if you have an ESLint rule that enforces line-endings to be LF, then your entire file buffer in Visual Studio Code will be underlined due to warnings/errors! Overwhelming as hell!!!
This is pain, and that's what happened to me once. Untangling that tuxedo situation is how I started investigating the case of CRLF vs LF in Git and finally wrote a LinkedIn post about it!
To fix:
Try not having such an ESLint rule. One that strictly checks line-endings to be LF or CRLF.
Create an
.editorconfigfile in project root with:
root = true
[*]
end_of_line = lf
Then install the EditorConfig extension. This way, Visual Studio Code will not save the file with CRLF (the default in Windows), rather will follow the end_of_line option.
And that's it. Another wrap on another fussy issue. If you have a question, let me know. I'd love to answer and try helping you out!
Thanks for reading and have a great one 👋
Top comments (2)
We should add, according to the ASCII Standard, CRLF is the correct line ending.
Indeed @jamescurran that is the correct line-ending.
According to the ASCII Standard and the history.