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

On Fri, May 7, 2010 at 5:54 PM, Linus Torvalds
[off-list ref] wrote:

On Fri, 7 May 2010, Avery Pennarun wrote:

quoted

quoted

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:

quoted

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