From: Avery Pennarun Date: Fri, 07 May 2010 22:19:52 GMT Subject: Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization Message-ID: In-Reply-To: On Fri, May 7, 2010 at 5:54 PM, Linus Torvalds 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