Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

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.

like image 545
Chris Avatar asked Mar 29 '12 20:03

Chris


People also ask

How do I change from CRLF to LF in Git?

text eol=crlf Git will always convert line endings to CRLF on checkout. You should use this for files that must keep CRLF endings, even on OSX or Linux. text eol=lf Git will always convert line endings to LF on checkout. You should use this for files that must keep LF endings, even on Windows.

Should I use CRLF or LF?

Whereas Windows follows the original convention of a carriage return plus a line feed ( CRLF ) for line endings, operating systems like Linux and Mac use only the line feed ( LF ) character. The history of these two control characters dates back to the era of the typewriter.

What is LF and CRLF in Git?

In Unix systems the end of a line is represented with a line feed (LF). In windows a line is represented with a carriage return (CR) and a line feed (LF) thus (CRLF). when you get code from git that was uploaded from a unix system they will only have an LF.


1 Answers

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".
like image 128
Chris Avatar answered Oct 21 '22 01:10

Chris