How to to disable Git end-of-line (CRLF to LF) acr

问题:

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.

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