Definitive recommendation for git autocrlf settings

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?

Solution 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").

Solution 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.

Solution 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!