Why should I use core.autocrlf=true in Git?

I have a Git repository that is accessed from both Windows and OS X, and that I know already contains some files with CRLF line-endings. As far as I can tell, there are two ways to deal with this:

Set core.autocrlf to false everywhere,
Follow the instructions here (echoed on GitHub's help pages) to convert the repository to contain only LF line-endings, and thereafter set core.autocrlf to true on Windows and input on OS X. The problem with doing this is that if I have any binary files in the repository that: a). are not correctly marked as binary in gitattributes, and b). happen to contain both CRLFs and LFs, they will be corrupted. It is possible my repository contains such files.

So why shouldn't I just turn off Git's line-ending conversion? There are a lot of vague warnings on the web about having core.autocrlf switched off causing problems, but very few specific ones; the only that I've found so far are that kdiff3 cannot handle CRLF endings (not a problem for me), and that some text editors have line-ending issues (also not a problem for me).

The repository is internal to my company, and so I don't need to worry about sharing it with people with different autocrlf settings or line-ending requirements.

Are there any other problems with just leaving line-endings as-is that I am unaware of?

The only specific reasons to set autocrlf to true are:

avoid git status showing all your files as modified because of the automatic eol convernsion done when cloning a unix-based eol Git repo to a Windows one (see issue 83 for instance)
and your coding tools somehow depends on a native eol style being present in your file:
- for instance, a code generator hard-coded to detect native eol
- other external batches (external to your repo) with regexp or code set to detect native eol
- I believe some Eclipse plugins can produce files with CRLF regardless on platform, which can be a problem.

Unless you can see specific treatment which must deal with native eol, you are better off leaving autocrlf to false.

@VonC Thanks! That helps me feel more confident that it's safe for me to use `autocrlf=false`. Out of interest, do you know why git still does eol conversion even if you have autocrlf set to false?

Rich 2010-05-13 10:45:18

@Rich I believe Git does eol conversion by default (i.e. if `autocrlf` is not set at all)

VonC 2010-05-13 11:10:24

@VonC: I don't think this answer is correct. Using core.autocrlf=true on Windows works as expected. All files from the repo (which should have LF line endings in this scenario) are converted to CRLF line endings on checkout to a Windows PC. All files are converted back to LF line endings on commit from a Windows PC. The way to get in trouble is to checkout initially to a Windows PC with the wrong core.autocrlf setting (which is entirely too easy to do).

Michael Maddox 2010-07-09 11:30:41

@Michael: I believe the issue was mainly when used in conjunction with `git svn`: the result had a `git status` reporting many differences between the index and HEAD. For a classic clone (no svn), you are right.

VonC 2010-07-09 12:42:43

@Michael So in that case is the only reason not to use `core.autocrlf=false` in my scenario be if I had some tool/editor that would get confused by the line-endings?

Rich 2010-07-14 16:07:36

@Rich: I don't know the answer to your original question, but I did give you a +1 for the question as I think it's interesting and relevant.

Michael Maddox 2010-07-14 17:08:47

@Michael: Thanks! We've set it to `false` here and I'll add my own answers if we come across any problems.

Rich 2010-07-27 10:34:35

ansaurus

tags:

views:

answers:

Why should I use core.autocrlf=true in Git?

related questions