On Fri, May 7, 2010 at 5:54 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html