Git’s core.autocrlf More Trouble Than It’s Worth

I’ve been using Git for some projects lately, and overall I have to say it’s a good tool. One thing that has had me scratching my head for a while is the behavior of line endings. There is a lot of conflicting advice on the Web regarding the ‘best’ usage of the core.autocrlf option across different platforms. After much wasted time trying to figure out why my working tree showed modifications even after a fresh checkout, I’ve concluded the best course of action is to always set the option to false. Pretty much any IDE or text editor these days, as well as any compiler one could consider using, supports either line ending mode. Git will get confused if some files in the repository have CRLF endings and others have LF, thinking you have made changes when you have made none. In this situation, git diff will list an entire file’s contents as removed, followed by the same exact content added (well, not exactly the same… the line endings are different! But who cares?) A git diff -w, on the other hand, will not list out this absurdity. Just do a git config core.autocrlf false followed by a git reset --hard and things will be where you want them. Let the IDEs deal with the line endings, and Git is happier to just deal with content tracking however it comes at it, and I’m happier to get back to real work rather than mucking about with the tool.

One thought on “Git’s core.autocrlf More Trouble Than It’s Worth”

  1. Thanks for the advice. I don’t understand the point of using core.autocrlf if it’s going to tell me that my files change every time I update or clone my repositories on different platforms.

    SVN doesn’t seem to give me this trouble, I really don’t want to have all my files line endings changing each time I test code on Mac/Windows.

Leave a Reply

Your email address will not be published. Required fields are marked *