Git on Windows: what do crlf settings mean?

Question

I don't understand the difficulties associated with CrLf settings in git: core.autocrlf , core.safecrlf

I am developing a cross-platform project as a team and would like Windows and Linux developers to be able to work together without git marking files as modified just because of the line ending style.

What do the various settings mean? What would be the consequences of choosing any of the options? And what would be the best solution for my case?

Yes, I know this question , and the answers there were not insightful, so this did not help.

Answer 1

Three values ​​for autocrlf :

• true - when content is sent to the repository (it is fixed), its line endings will be converted to LF, and when the content leaves the repository (crossed out), line endings are converted to CRLF. This is generally intended for unfamiliar Windows users / editors. Given the assumption that the editor (or user) is going to create files with CRLF endings and will worry if he sees the normal LF endings, but you want the LF endings in the repo, this hopefully covers you. However, it is possible that everything goes against it. In related matters, there are examples of false merge conflicts and reports of modified files.

• input - when the content enters the repository, its line endings will be converted to LF, but the content remains untouched on the output. This is basically in the same realm as true , provided that editors can actually deal with LF endings correctly; you simply warn against the possibility of accidentally creating a file ending in CRLF.

• false - git doesn't touch line endings at all. It is for you. This is what many recommend. With this option, if line endings in files are started, you will need to be aware of this, so merge conflicts are much less common (assuming informed users). Teaching developers how to use their editors / IDEs can pretty much take care of the problem. All the editors I've seen for programmers can handle this if they are configured correctly.

Note that autocrlf will not affect content that is already in the repository. If you have already done something with the end of the CRLF, they will remain so. This is a very good reason to avoid autocrlf dependency; if one user has not installed it, they can get content with CRLF ends in the repo, and he will stick. A stronger way to force normalization is through an attribute; setting it to auto for a given path, it marks it to normalize the end of the line, assuming git decides that the content is text (not binary).

A related safecrlf option, which is basically a way to make sure you are not doing the raw CRLF conversion in the binary.

I don't have much experience with Windows and git issues, so feedback on issues / errors is certainly welcome.

Answer 2

I examined 3 possible values ​​for cases of commit and check, and this is the resulting table:

 ╔═══════════════╦══════════════╦══════════════╦══════════════╗ ║ core.autocrlf ║ false ║ input ║ true ║ ╠═══════════════╬══════════════╬══════════════╬══════════════╣ ║ git commit ║ LF => LF ║ LF => LF ║ LF => LF ║ ║ ║ CR => CR ║ CR => CR ║ CR => CR ║ ║ ║ CRLF => CRLF ║ CRLF => LF ║ CRLF => LF ║ ╠═══════════════╬══════════════╬══════════════╬══════════════╣ ║ git checkout ║ LF => LF ║ LF => LF ║ LF => CRLF ║ ║ ║ CR => CR ║ CR => CR ║ CR => CR ║ ║ ║ CRLF => CRLF ║ CRLF => CRLF ║ CRLF => CRLF ║ ╚═══════════════╩══════════════╩══════════════╩══════════════╝ 

I would recommend using core.autocrlf = input on all platforms. In this case, if Git encounters CRLF it will implicitly convert it to LF , and existing files with LF remain as they are.

Answer 3

Fyi. By default, a line ending in Windows will force CRLF and Linux to take LF. Please find the table below for a clear understanding.

 ╔═══════════════╦══════════════╦══════════════╦══════════════╗ ║ core.autocrlf ║ false ║ input ║ true ║ ║ ║ Win => Unix ║ Win => Unix ║ Win => Unix ║ ╠═══════════════╬══════════════╬══════════════╬══════════════╣ ║ git commit ║ LF => LF ║ LF => LF ║ LF => LF ║ ║ ║ CR => CR ║ CR => CR ║ CR => CR ║ ║ ║ CRLF => CRLF ║ *CRLF => LF ║ *CRLF => LF ║ ╠═══════════════╬══════════════╬══════════════╬══════════════╣ ║ git checkout ║ LF => LF ║ LF => LF ║ *LF => CRLF ║ ║ ║ CR => CR ║ CR => CR ║ CR => CR ║ ║ ║ CRLF => CRLF ║ CRLF => CRLF ║ CRLF => CRLF ║ ╚═══════════════╩══════════════╩══════════════╩══════════════╝ 

In the above table information, the * symbol emphasizes the differences between Windows and Unix. At a glance, below is the CLRF information based on OS platforms:

---

For Windows users

• If Windows users work with cross-platform projects, It MUST be core.autocrlf=true for Windows machines and core.autocrlf=input for Unix machines.
• If Windows users work only with Windows projects, it can be either core.autocrlf=true or core.autocrlf=false . But core.autocrlf=input will cause problems in this case.

---

For Unix users (Linux / Mac OS)

• If Unix users work with cross-platform projects, It MUST will be core.autocrlf=true for Windows machines and core.autocrlf=input for Unix machines.
• If Unix users work only with Unix projects, it can be either core.autocrlf=input or core.autocrlf=false . But core.autocrlf=true will cause problems in this case.

---

For the same OS users

• For a clean Windows project or a clean Unix project, this could be core.autocrlf=false .

Answer 4

I get this error: the file will have the original end of the line in your working directory. warning: LF will be replaced by CRLF with DV / debug.log. and then "fatal: file failure failed"