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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: May 7, 2010, 21:54 UTC
Message-ID: <alpine.LFD.2.00.1005071441341.901@i5.linux-foundation.org>
In-Reply-To: <m2z32541b131005071430vcd851ac8yd3c783429a84f875@mail.gmail.com>

On Fri, 7 May 2010, Avery Pennarun wrote:

Show 7 quoted lines

>
> > 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.

I just think that it's crazy because

 (a) you should try to avoid do things like that in the first place. For 
     something like an attribute file, you should just list the files you 
     want to convert. That's the _point_ of an attribute. So it's much 
     nicer if you instead actually are explicit about it, ie

	*.[ch] crlf
	*.txt crlf
	*.jpg -crlf

     should be the _primary_ way you do it, since the autocrlf thing is a 
     bit dangerous in theory.

 (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

     No? Not some totally new attribute name.

And in the end, you always do want to have a config variable for the actual type of conversion. And like it or not, we already do end up having this mix-up between .gitattributes and git "core.autocrlf" config entry, so my suggested rule was kind of a "minimally invasive" suggestion to just turn that mixing of attributes and config entries into something more practically useful.

		Linus