Definitive recommendation for git autocrlf settings

Question

I use Windows, Mac OS X and linux on a daily basis. I use git in all these environments, pulling from repos that are used by folks with different choices for line endings.

Are there definitive recommendation for setting core.autocrlf in my situation?

Gratification

Answer 1

I would recommend, as I did in this SO question, to set it to false.

If you can avoid modifying any eol (with your editor), then it would be best to push back your work with those eol unchanged (i.e. "as you found them").

Buber

Note for self: one tricky side-effect of autocrlf at true: #2016904 – Buber

I agree, unfortunately autocrlf causes a ton of problems and makes conflicts appear where they don't exist. – Octarchy

One big problem is if the windows line endings are already in the repository (e.g. if using git-svn), and then your git messes it all up locally. – Blastopore

Answer 2

One issue that is often not mentioned in these discussions: if you develop shell scripts on windows (say, in cygwin) and commit them with CRLF (autocrlf=false), they will crash on *nix boxes with useless error messages. (There may be similar cases with other scripting languages.) After scratching your head for a half-hour, you will remember and then dos2unix the little rascals. If you work in a mixed environment (say deploying from Windows to a linux server) and you absolutely want to set autocrlf to false, then MAKE SURE that all your windows editors use unix (lf) line endings. Otherwise set autocrlf to input (and pray). Most 21st Century Windows programs are comfortable without the early 1980's line printer CRs, so it's a good idea to set your line-endings to LF (unix) anyway.

Womenfolk

Well, Cygwin actually seems to require LF line endings in shell scripts. Maybe MinGW/MSYS bash could use shell scripts with CRLF, I'm not sure. But I found that core.autocrlf=true means that Cygwin fails to execute shell scripts checked out this way... – Quag

The ideal solution to this would be for all tools to support both types of line endings, then we could finally put this most pointless waste of time of an issue behind us. And for once, Windows is ahead of Unix in this regard. – Sportswoman

A new complication that didn't exist in 2011: if you write shell scripts on Windows, with the intent to sometimes locally run a docker build, CRLF even in your local workspace will ruin your day. In this case you have to "MAKE SURE" that your editor(s) all dutifully write only LFs from the beginning, regardless of what you are doing with git. – Funch

Answer 3

GIT would NOT have common SHA1's for two text files with identical text but different end-of-line(EOL) mechanisms inside the binary representation. The content is stored as a blob, which is reused if another identical copy is de-posited into the re-pository (space saving!)

The default choice taken by (the) GIT (designers) is to use the *nix style EOL character (LF only) whenever possible, so that for the same text content you get the same SHA1. (probably an important consideration ;-)

Because the content/blob no longer remembers the user's original EOL choice (remember it's possibly now in some distant repository) , Git has to make some guesses (option based) about how to recreate the original user's file (was it CRLF or was it simply LF) in a manner that you (and your tools) can use.

The normal recommendation is that locally each user (a) converts to *nix LF endings when committing into a blob (so all will see common SHA1 blob names) (a/k/a the Right Thing), and (b) locally set the re-creation option to their local system setting e.g. *nix(LF) or Windows(CRLF), etc.

Set some local standards for your users, and have the one big 'EOL/LF/CRLF & Whitespace Correction commit', and you'll be fine (plus training re-training of new users)

You can also make sure you (each user) uses a common white-space adjustment setting so that tabs v spaces, and trailing whitespaces doesn't cause more diff inconveniences!

Blank

A good reason to follow LF storage internally (which may result in setting autocrlf to true). Moreover: it is my experience, that applying patches may fail when files are stored with CRLF in blobs, even when the patch files also have CRLF in the diff content parts. – Medawar

This behavior I have been pestering about for long now suddenly makes sense. Thank you for that. However, I find it incomprehensible that Git does not respect the setting when doing merges: I'm on Windows and have autocrlf to true, but after any merge from other Linuxers on the team, my files that were involved/touched in the merge end up with LF on all lines. – Heinz

@Heinz What are the respective settings. It would be good to get a MVCE for this to report to the Git Dev List. If you have some CRLF in the repo and they have LF, then the result is probably mixed, and may need a --no-commit and a --renormalize to tidy up. – Blank

The rest of the team is on Ubuntu so I don't think they have configured autocrlf. It is very probable that our GitHub repositories contain mixed line endings: the previous team manager was also on Windows and I know for sure that he didn't have autocrlf set to true. Thanks. – Heinz