Correct setting for git autocrlf as per use case

Question

I was searching for the proper setting to be used as per certain use cases but could not find any source describing the same. Therefore, I am asking this question to serve as a solution to anyone looking for the correct setting for git's autocrlf option.

Use Case 1: I am on Mac, the other developers are all on Windows. They are managing the source code before I joined in.

Use Case 2: I am on Windows, the other developers are all on Mac. They are managing the source code before I joined in.

Use Case 3: I am on Linux, the other developers are all on Windows. They are managing the source code before I joined in.

Use Case 4: I am on Windows, the other developers are all on linux. They are managing the source code before I joined in.

Use Case 5: I am on Linux, the other developers are all on Mac. They are managing the source code before I joined in.

Use Case 6: I am on Mac, the other developers are all on Linux. They are managing the source code before I joined in.

What setting of git core.autocrlf should I be using ?

EDIT: Why this question is not a duplicate to many similar questions:

All other questions and their answers provide the required facts and knowledge that leaves a lot to be done by the reader. This question aims at asking the specific answer to specific scenarios.

Barometrograph

Possible duplicate of git replacing LF with CRLF – Stud

I have seen almost all the questions related to the same but no one asks specifically the setting to be used for a particular use case. All these questions provide the knowledge but does not answer what to do :) – Barometrograph

You shouldn't use core.autocrlf, you should set up your .gitattributes correctly instead. – Appropriation

Thanks Edward, I would appreciate if you can please explain it more through an answer. – Barometrograph

Answer 1

Simple:

 git config core.autocrlf false

(for all and any scenario)

core.autocrlf is a config, which means it is not pushed or cloned with the repo: it has to be set by the user.

It was the legacy way to handle eol at the repo level.

What you want to use (add or modify depending on your scenario) are gitattributes core.eol directives.

• .gitattributes is a file which can be managed in the git repo like any other file. Once you agree on an eol policy, that policy will be enforced at each clone.
• you can set core.eol directives for a file, or group of files if you want (as opposed to the global repository-wide config core.autocrlf)

For heterogeneous environment, the core.eol (only for the files you deem problematic) should be native (if you suspect your editor insist on using the system eol instead of using the one already present in the file).

For more, see "Mind the End of Your Line".

Toleration

Answer 2

Don't worry about core.autocrlf; add a .gitattributes file in the root directory and put the following line in:

* text=auto

This will cause git to automatically convert all line endings to LF on commit, and (for Windows machines) convert line endings to CRLF on checkout.

Note that for use case 1 and 3, where the existing developers are on Windows, adding this line to .gitattributes may make it look like you all of a sudden have a ton of changes to commit. That is because you have a lot of files with CRLF in them in the repository, and git knows it has to convert them all to LF. Go ahead and commit those changes, even though it looks like nothing has really changed.

One other thing to note is that if everyone is on the same OS, then I wouldn't even mess around with converting line endings; in that case, put the line * -text in your .gitattributes file so that no conversion happens.

Swingle