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

On Fri, 7 May 2010, Avery Pennarun wrote:

Maybe we should rethink this from the top.  Imagine that we currently
have no crlf options whatsoever.  What *should* it look like?  I
suggest the following:

Config:
   core.eolOverride = lf / crlf / auto / binary / input
   core.eolDefault = lf / crlf / auto / binary / input

Ugh. Hell no. What an ugly format. What does that crazy "override vs 
default" even _mean_?

So no.

Plus the above is confused anyway. The only reason to ever support 'lf' is 
if you're a total moron of a SCM, and you save files you know are text in 
CRLF format internally. That's just f*cking stupid.

So the above is just crazy talk.

The options that make sense is:

 - disabling all "text" issues, and considering everything to be pure 
   binary. This is the "I know I'm sane and unix" option, or the "doing 
   any conversion is always wrong" option.

   We'd call this "binary" or "off" or "false".

 - if you recognize a text-file, and consider it text and different from 
   binary, at a _minimum_ it needs what we call "input". Anything else is 
   crazy-talk. We don't save the same text-file in different formats, and 
   we know that CRLF (or CR) is just a stupid format for text.

   So there are zero options for the input side. If we don't do CRLF -> LF 
   conversion on input, it's worthless even _talking_ about text vs binary.

 - For output, there are exactly three choices: "do nothing" (aka just 
   "input", aka "LF"), output in native format (CRLF on Windows, LF on 
   UNIX), or "force CRLF" regardless of any defaults (and the last 
   probably doesn't make sense in practice, but is good for test-suites, 
   so that you can get CRLF output even on sane platforms.

So I think the _only_ sane choices are basically

	core.crlf=[off|input|on|force]

where you may obviously have aliases (ie "off", "false" and "binary" could 
all mean the same thing, and you could alias "input" to "lf" and "force" 
to "crlf").

And the above is basically what we have. Except that for historical 
reasons (ie we didn't even _have_ any attributes) it got mixed it up with 
"do we want to do this automatically", so "autocrlf=on" actually ends up 
being "yes, do automatic detection" _and_ what I'd call "core.crlf=force" 
above.

			Linus