Git tries to help translate line endings between operating systems with different standards. This gets sooo frustrating. Here’s what I always want:
On Windows:
git config --global core.autocrlf input
This says, “If I commit a file with the wrong line endings, fix it before other people notice.” Otherwise, leave it alone.
On Linux, Mac, etc:
git config --global core.autocrlf false
This says, “Don’t screw with the line endings.”
Nowhere:
git config --global core.autocrlf true
This says, “Screw with the line endings. Make them all include carriage return on my filesystem, but not have carriage return when I push to the shared repository.” This is not necessary.
Windows and Linux on the same files:
This happens when you’re running Linux in a docker container and mounting files that are stored on Windows. Generally, stick with the Windows strategy of core.autocrlf=input, unless you have .bat or .cmd (Windows executables) in your repository.
The VS Code docs have tips for this case. They suggest setting up the repository with a .gitattributes file that says “mostly use LF as line endings, but .bat and .cmd files need CR+LF”:
* text=auto eol=lf
*.{cmd,[cC][mM][dD]} text eol=crlf
*.{bat,[bB][aA][tT]} text eol=crlf
If VSCode insists on putting CR (pictured as ^M in the git diff) in a file, then open the file and check the lower right-hand corner, in the status bar. Does it say “CRLF”? Click that and choose “LF” instead. Do things right, VSCode 😠
Troubleshooting
When git is surprising you:
Check for overrides
Within a repository, the .gitattributes file can override the autocrlf behavior for all files or sets of files. Watch out for the text and eol attributes. It is incredibly complicated.
Check your settings
To find out which one is in effect for new clones:git config --global --get core.autocrlf
Or in one repository of interest:git config --local --get core.autocrlf
Why is it set that way? Find out:git config --list --show-origin
This shows all the places the settings are set. Including duplicates — it’s OK for there to be multiple entries for one setting.
Why does this even exist?
Historical reasons, of course! (If you have a Ruby Tapas subscription, there’s a great little history lesson on this.)
Back in the day, many Windows programs expected files to have line endings marked with CR+LF characters (carriage return + line feed, or \r\n). These days, these programs work fine with either CR+LF or with LF alone. Meanwhile, Linux/Mac programs expect LF alone.
Use LF alone! There’s no reason to include the CR characters, even if you’re working on Windows.
One danger: new files created in programs like Notepad get CR+LF. Those files look like they have \r on every line when viewed in Linux/Mac programs or (in code) read into strings and split on \n.
That’s why, on Windows, it makes sense to ask git to change line endings from CR+LF to LF on files that it saves. core.autocrlf=input says, screw with the line endings only in one direction. Don’t add CR, but do take it away before other people see it.
Postscript
I love ternary booleans like this: true, false, input. Hilarious! This illustrates: don’t use booleans in your interfaces. Use enums instead. Names are useful. autocrlf=ScrewWithLineEndings|GoAway|HideMyCRs