Re: [PATCH/RFC v2 1/4] Add "core.eolStyle" variable to control end-of-line conversion

From: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Date: May 9, 2010, 08:13 UTC
Message-ID: <A5422145-63E1-4AF4-9184-7A6D15E9C2B6@gmail.com>
In-Reply-To: <alpine.LFD.2.00.1005081600490.3711@i5.linux-foundation.org>

On 9. mai 2010, at 01.08, Linus Torvalds wrote:

Show 5 quoted lines

> On Sun, 9 May 2010, Eyvind Bernhardsen wrote:
>> 
>> Heh. How about "localcrlf={true,false,native}"?
> 
> I really don't understand that. What would it even mean?

Sorry, I should have explained it.  I chided you for "crlf=input" being crazy, but then I realized that "crlf=true" really isn't too bad a config variable for saying that you want CRLFs.  Just "crlf" seems a bit obscure still, so I came up with "localcrlf": if it's "true" it means you want CRLFs locally (in your working directory), if it's "false" you want LFs.

It helps to think about the situations where you're likely to change this. If you're on Linux but you want CRLFs in your working directory, set "localcrlf=true".  If you're on Windows but don't want CRLFs, "localcrlf=false".  Thinking about it, "input" could be an alias for "false", which would make it _exactly_ what you suggested except for a slight clarification in the name.

> An you _do_ realize that like it or not, we already have "crlf=input" as 
> the syntax in our .gitattributes files? So that exact syntax already 
> exists in one place.

I'm sorry.  Are you the same Linus Torvalds who wrote this:

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

?  I agree with that sentiment.  "crlf=input" is silly; if you have a file that always has to be LF no matter what, just set it to "-crlf" and make sure you don't accidentally introduce any CRs.  That is what you have to do for a file that always has to be CRLF, after all.  As always, I'm not suggesting getting rid of "crlf=input"; I would keep it for backwards compatibility, but not emphasize it in the documentation.

> As mentioned, I really can understand people not liking the name, but we 
> already _have_ that name, and that syntax. I think it makes more sense to 
> try to have a unified syntax than have two different strings for the same 
> thing.

I agree with this!  I just don't agree that the unified syntax should be married to the old, poor syntax, and "crlf=input" is a straw man.  It's both ugly and unnecessary.

Show 5 quoted lines

> So I think we'd be better off with good documentation with a couple of 
> real examples (and easily findable), so that the naming is at least 
> something people can look up and see the semantics for. The "eol" vs 
> "crlf" thing is just bike shedding, and we already ended up with "crlf". 
> In contrast, making docs understandable is more than bikeshedding.

Making the docs understandable is important.  I have changed the docs, and I will keep trying to improve them.  But making the configuration understandable is _also_ important!  It's not just the colour of the bike shed, it's how it _works_.  This discussion is not a waste of time.

But if you insist, here's how it looks to me: I'm the one trying to build a new bike shed from the parts of the grotty one that nobody really likes to use, and you're the one saying I need to paint it in the same 70s brown-and-mustard colour scheme as the old one.

The frustrating thing is that you're also coming up with some interesting colour combinations elsewhere, but you seem resigned to the idea that we're stuck with the ugliness.  I don't think we are.

-- 
Eyvind