How to to disable Git end-of-line (CRLF to LF) across all clones/machines?

Question

As one can glean from other posts, Git's end-of-line normalization has its pros and cons. I have one particular Windows-only project where I think the best thing to do is to is to disable end-of-line normalization altogether. That is, I want to leave all newlines (most of which are CRLF) intact, rather than have git normalize them to LF-only behind the scenes, and I want that change to affect all clones of the repository on all machines. The question is the most effective way to do it.

Most discussions of Git end-of-line normalization are in terms of core.autocrlf, and I could accomplish my goal by setting core.autocrlf=false. However, this is a git-config setting, and I believe one has to set that separately on each machine by machine. If true, that seems error prone, especially since the msysgit installer guides one into setting core.autocrlf=true.

Dog

Answer 1

The best way to avoid having to set core.autocrlf separately on each machine seems to be checking a .gitattributes file into the repository containing the single line

* -text

Or, if you have an older version of Git then

* -crlf

This tells Git that, for all paths (thus the *), end-of-line normalization should not be attempted. As far as I can tell, this should not have any other side-effects. In particular, it should not alter how diffs are generated (this has separate attribute diff/-diff) or how merges are handled (this has a separate attribute merge/-merge).

For more details, I suggest these resources:

1. The gitattributes documentation (git help attributes or an online copy) , which describes in detail both how end-of-line normalization works and the particular effects of different attributes. (Probably most relevant are text, crlf, diff, merge, and binary.)
2. Git mailing list thread Is the "text" attribute meant only to specify end-of-line normalization behavior, or does it have broader implications? (Mar 30, 2012), which expands on the meaning of different attributes, and clarifies that -text does not mean simply "this is a binary file".

Dog

The link in your post is dead. Maybe you could use this one instead? git.661346.n2.nabble.com/… – Deluna

With core.autocrlf=true (default), doesn't Git modify the line endings on checkout? Which is before it can even read the .gitattributes? (The .gitattributes itself will have CRLF). Then, on commit, Git is told to not convert the CRLFs (-text) so you end up with CRLFs in your repo? – Guzman

@MichelJung git can read .gitattributes from the local repository after it has pulled from the remote repository, but before the files are checked out. The local repository should match the remote repository in its line endings. It is only at the point of checking the files out and committing them back in, that line ending conversions are performed. – Hotfoot