Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: May 7, 2010, 22:14 UTC
Message-ID: <alpine.LFD.2.00.1005071504280.901@i5.linux-foundation.org>
In-Reply-To: <alpine.LFD.2.00.1005071441341.901@i5.linux-foundation.org>

On Fri, 7 May 2010, Linus Torvalds wrote:

Show 5 quoted lines

> 
>      IOW, if you really want to say "do automatic crlf for this set of 
>      paths", the natural syntax for that would be
> 
> 	* crlf=auto

Btw, since we're discussing this, I do think that our current "crlf=input" syntax for .gitattributes is pretty dubious.

I don't really see why it should be a path-dependent thing on whether you do crlf conversion on just input or on checkout too. It smells odd. It makes more sense to me to have a global policy for what the output/input conversion should be, and then the path rules are just about whether that conversion gets done or not.

And like it or not, we called that global rule "autocrlf", and then mixed it up with the decision on whether we should do conversion at all. I do think that that was a mistake too, and that we could try to fix it, but I also think that's a fairly independent issue.

So we _could_ introduce a new "core.crlf" config option that talks purely about what kind of conversion gets done - not about _whether_ it gets done. So you could do

	[core]
		crlf=input

and it would imply that crlf conversion is only done on input, but it would differ from "autocrlf=input" in that it would _not_ imply that any paths not matched by gitattributes crlf rules would be automatically converted.

[ And in the above model, "core.autocrlf = input" would just be a 
  shorthand for saying "core.autocrlf=true" + "core.crlf=input")

So I think we could improve the config file syntax a bit.

But I think that's really a separate issue from the .gitattributes file, and whether the "crlf" attribute means anythin in the _absense_ of any config file rules about crlf.

			Linus