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

[Avery Pennarun <apenwarr@gmail.com>]

On Fri, May 7, 2010 at 4:06 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Fri, 7 May 2010, Avery Pennarun wrote:
>> No!  The whole point is that each user *does* still want to be able to
>> decide how to convert the files tagged by the crlf gitattribute (or a
>> new attribute, I don't care).
>
> Avery, you really don't _get_ it, do you?

I was going to say that I do get it, but I guess I didn't.  You're
right, your proposal is functionally equivalent.  Feel free to stop
reading the rest of this post :)

For the benefit of those who might have misunderstood as I did, the
reason they're equivalent is that "core.eolStyle = LF" is the same as
saying "never do EOL conversion" since an unconverted file is
implicitly LF.  And there is already a way to say "never do EOL
conversion," which is to set core.autocrlf=False.

By adding core.autocrlf=True to an in-project .gitconfig file, we can
fix a mistake in the original definition of the crlf attribute, ie.,
it should be able to force CRLF conversion even when a user hasn't set
core.autocrlf explicitly.  But that new ability doesn't take away a
person's ability to override it globally because .git/config and
~/.gitconfig take precedence.  Notably, this solution doesn't break
any backward compatibility.

Linus's second proposed option would be to slightly change the way the
crlf attribute works, by making core.autocrlf a tri-state variable
instead of just true/false.  "Undefined" would mean "use the crlf
attribute" where currently it means (rather unhelpfully) "always use
LF even if .gitattributes says otherwise."  However, this would be a
backward-incompatible change.  Arguably, not one that anyone would
care about.  (For the record, none of my co-workers would care.  The
current behaviour is sufficiently unhelpful that we have to use
core.autocrlf=True anyway, so .gitattributes crlf hasn't been useful.)

Now, arguably, the current semantics, and even Linus's proposed
improved semantics, are still pretty hard to explain.  "This file
should always be unchanged" and "this file should always use native
line endings" and "this is my native line ending style" is very simple
and straightforward.  But I'm sure others would argue the opposite,
and it's just a matter of preference.

Have fun,

Avery