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.

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