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

[Avery Pennarun <apenwarr@gmail.com>]

On Fri, May 7, 2010 at 5:54 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Fri, 7 May 2010, Avery Pennarun wrote:
>> > I think "* auto-eol=true" is just crazy. We would _never_ want to do that.
>> > Any project that does that should be shot in the head.
>>
>> Just to clarify, is it crazy because that line would convert all
>> files, even binary ones, where core.autocrlf auto-detects whether
>> files are binary or text?
>
> No, presumably 'auto-eol' does the same auto-detection. Otherwise the name
> wouldn't make sense.
> [...]
> Eyvind Bernhardsen wrote:
>> Also, I meant to write "* crlf=auto", not "* auto-eol=true", if that makes it
>> any less crazy.
>
> Oh, yes. See my other email. "* crlf=auto" is at least sensible, although
> somewhat scary. At least with core.autocrlf=true, the user has to had
> [...]
>  (b) But let's say that you want to do it anyway (because you're lazy
>     and because autocrlf works pretty damn well in practice), isn't that
>     a really ugly and crazy thing to add _another_ attribute name for
>     that?
>
>     IOW, if you really want to say "do automatic crlf for this set of
>     paths", the natural syntax for that would be
>
>        * crlf=auto

Oh, good grief, I'm just getting more and more confused.

So just to keep all of this straight, I think there are still two
proposals under consideration here:

a) add an in-project .gitconfig, in which case the above crlf=auto is
exactly equivalent to "crlf attribute missing" (which is different
from "crlf unset", hee hee, are we having fun yet?) since the crlf
attribute is ignored unless core.autocrlf=true, and missing means to
use the core.autocrlf setting;

OR

b) change the semantics of the crlf attribute, in which case crlf=auto
is a new mode that means "use autocrlf on this file even if
core.autocrlf is unset or unspecified".

Right?  So in case (a), the new crlf=auto option is unneeded.  Though
it does seem as if we're trending toward case (b).

Thanks,

Avery