views:

4616

answers:

3

I tried committing files with CRLF-ending lines but it failed.

I spent a whole work day on my Windows computer trying different strategies, and was almost drawn to stop trying to use git and instead try mercurial.

Please share only one best practice per answer.

+14  A: 

Don't convert line endings. It's not the VCS's job to interpret data -- just store and version it. Every modern text editor can read both kinds of line endings anyway.

John Millikin
Seconded. If you have problems with inconsistent line-endings, the best solution is shout at whoever's using the wrong editor settings until they fix it.
I'd be happy with this strategy, but - were I doing something wrong? - git would refuse my commits if I didn't convert files manually using dos2unix, or if I didn't configure it with autocrlf. Something like "patch contains suspicious lines" and, some other times, "suspicous whitespace at eol"
Daniel Jomphe
Daniel: I don't use Git, but that's likely a configuration option in the repo.
John Millikin
Disagree. Native linefeeds on all platforms is a convenience.
Jonas Byström
This is an EXTREMELY useless answer. Does Git have an option not to convert line endings? If so, what is it? Git users have no choice, and this is specifically a Git question.
ראובן
Visual Studio is a PITA when it comes to anything other than CRLF.
Brett Ryan
+8  A: 

Try setting the core.autocrlf configuration option to true. Also have a look at the core.safecrlf option.

Actually it sounds like core.safecrlf might already be set in your repository, because (emphasis mine):

If this is not the case for the current setting of core.autocrlf, git will reject the file.

If this is the case, then you might want to check that your text editor is configured to use line endings consistently. You will likely run into problems if a text file contains a mixture of LF and CRLF line endings.

Finally, I feel that the recommendation to simply "use what you're given" and use LF terminated lines on Windows will cause more problems than it solves. Git has the above options to try to handle line endings in a sensible way, so it makes sense to use them.

Greg Hewgill
I too thought autocrlf with safecrlf was useful, but with a repo whose files' line endings are CRLFs, if I remember well, on a commit, git would translate them to LFs and the whole file would be marked as changed. ...Obviously, I need to try again the whole thing to see if I could better this time.
Daniel Jomphe
+10  A: 

It should be either core.autocrlf=true if you like DOS ending or core.autocrlf=input if you prefer unix-newlines. In both cases, your Git repository will have only LF, which is the Right Thing. The only argument for core.autocrlf=false was that automatic heuristic may incorrectly detect some binary as text and then your tile will be corrupted. So, core.safecrlf option was introduced to warn a user if a irreversable change happens. In fact, there are two possibilities of irreversable changes -- mixed line-ending in text file, in this normalization is desirable, so this warning can be ignored, or (very unlikely) that Git incorrectly detected your binary file as text. Then you need to use attributes to tell Git that this file is binary.

Hat tip: http://kerneltrap.org/mailarchive/git/2008/4/16/1450834/thread

Cory
Why it is a "Right Thing"?
Artem Tikhomirov
core.autocrlf=true is a terrible idea. I've had nothing trouble with that option, plus you have to remember to set it whenever you clone the repository.
Luís Oliveira
I suspect this answer is wrong. The advice is inconsistent with what I've read elsewhere.
Michael Maddox
Do NOT use autocrlf=true unless you know what you are doing. If you develop in DOS/Win then autocrlf=false will keep the endings the same between remote and local repo's and is the best option in almost every situation.
Chris Nicola