Re: [RFC/PATCH v3 4/5] Rename "crlf" attribute as "eolconv"

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: May 13, 2010, 21:45 UTC
Message-ID: <alpine.LFD.2.00.1005131438330.3711@i5.linux-foundation.org>
In-Reply-To: <961B7250-F65E-4C67-8C5C-6701F68C2FC0@gmail.com>

On Thu, 13 May 2010, Eyvind Bernhardsen wrote:

> 
> Do you agree that "native" eol should only be CRLF if autocrlf is true?

Not really. We're trying to get _away_ from .gitattributes depending on autocrlf, aren't we?

Show 6 quoted lines

> Otherwise, if .gitattributes looks like this:
> 
> 	*.txt text
> 
> git will put CRLFs in .txt files but LFs in .c files, and I don't think 
> that makes much sense.

Well, but that's what you asked for, isn't it? And I don't see why you say *.c files would have LF's, since that depends on what you put in them: and under Windows, that might well be CRLF.

And I do think it's perfectly reasonable to override the "native" mode in your .git/config. If we're renaming the attributes, we might as well then introduce a

	[core]
		eol=lf

to set the "native" EOL for that repo, exactly because presumably a number of Windows people would like to see the saner LF-only model rather than the traditional native CRLF.

In fact, maybe it would even make sense to just make LF the default "native" end-of-line sequence even on windows, so that Windows people who actually want CRLF would have to set core.eol=crlf. Whatever. That would be for the Windows git users to fight out, I don't care.

But if we are going to clean up text attribute handling, then I really think we want to totally break that old "core.autocrlf" dependency.

			Linus