Guides: Dealing with newlines in git

Line endings… the scourge of every Windows-based developer that tries to mingle with linux- or mac-based developers. Though most modern text editors can handle both newline types without issue, git is not as graceful.

For more info on the issue see Wikipedia.

I just cloned and git says files have changed!

So, you just cloned a repo on a Windows box, and it says that all of your files have been modified. Huh? You’ve not touched anything yet! What the…

The problem is that your “core.autocrlf” option is likely not enabled. This setting tells git to convert the newlines to the system’s standard when checking out files, and to LF newlines when committing in. To turn it on use this command:

git config --global core.autocrlf true

Once this is set, you need to reset your repos. The sad fact is that the best way to do this is wipe out your working tree (all the files except the .git directory) and then restore them:

git reset --hard HEAD

What this does is checkout a fresh working copy, this time filtering the newlines according to the autocrlf setting. At this point you may still have some files that show up as changed. This means that the files in your repo were using mixed newlines. Commit the files as they are without editing and git will convert them into consistent newlines.

Moving forward

Now that you’ve standardized the newlines in your repo things should be better. However, every person that touches your repo should turn autocrlf on, even non-Windows users. It is possible for them to bring in code from an outside source that has CRLF newlines, and you don’t want them saved into the repo like that.

For more details on the “core.autocrlf” setting see the git-config documentation.