Re: [RFC/PATCH v3 4/5] Rename "crlf" attribute as "eolconv"

On Thu, 13 May 2010, Eyvind Bernhardsen wrote:

...

If you are doing the renaming, then I seriously object to this.

It makes no sense to say "eolconv=crlf" and then say "eolconv=auto". They are two totally different things. One is _how_ line endings should look like, and the other is _whether_ line endings exist or not.

And "eolconv=crlf" makes no sense anyway. I assume "conv" is conversion, but a conversion implies a from and a to. That's just a "to", and it would make much more sense to just say "eol=crlf" for that case.

Now, it _does_ make sense to say "eolconv=auto", but that's because it's that totally different case: it's not about what the line ending character is, it's about whether any eol conversion is done at all. So for _that_ case, it makes sense to use "eolconv", although even for that case I think the name is not very _good_. So if you rename these things, keep them separate. Make the "am I a text-file" boolean be a boolean (plus "auto"), and just call it "text". And make the "what end of line to use" be just "eol" then.

So you can have

	*	text=auto,eol=crlf

that means "autodetect whether it is text, and use crlf as eol".

Now, I'd further suggest:

 - "eol=xyz" with no "text" attribute automatically implies "text" being 
   true.
 - "text=xyz" with no "eol" attribute implies "eol=native"

so now you can write:

	*.jpg -text
	*.txt text
	*.vcproj eol=crlf
	*.sh eol=lf
	* text=auto

and that means:

 - jpg files are binary
 - *.txt files are text, and we use the default ("native") line ending for 
   them (implicit, since we don't have any matcing eol rule)
 - *.vcproj files are text (implicit), and we use CRLF line endings
 - *.sh files are text (implicit), and we use UNIX style line endings
 - everything else is auto-detected, and we implicitly use native line 
   endings for them

Doesn't that look finally sane?

Because if we really renaem the attributes, let's rename them _right_.

			Linus