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

[Avery Pennarun <apenwarr@gmail.com>]

On Fri, May 7, 2010 at 3:16 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Fri, 7 May 2010, Avery Pennarun wrote:
>> Unfortunately this option wouldn't be as flexible as Eyvind's current proposal.
>
> Oh, absolutely it is.
>
>> What his method allows is to mark some files in a project as "these
>> should be the native EOL style" and others as "these should be left
>> alone."
>
> But that's what a .gitconfig would too. We _already_ have that
> .gitattribute thing to then distinguish particular pathname rules. It's
> just that currently .git/config is needed to _enable_ it.

Hmm, I don't think we're saying the same thing.  There are two
separate settings here:

1) Whether a project has files that should be EOL-converted
automatically (we seem to all agree that this is set in
.gitattributes, whichever attribute is used).

2) Whether a particular person wants those particular files to be
EOL-converted, and what to convert them to.

The existing semantics of core.autocrlf just don't let you express #2
in a useful way.  If I set --global core.autocrlf, it turns it on for
*all* projects, not just ones with the .gitattribute set.  If a
project has a .gitconfig inside that sets core.autocrlf, then it's
really just redundant with #1.  If I set .git/config on a particular
project, it works, but it's far too easy to forget (and there seems to
be no way to set this per-project at clone time, and setting it
*after* cloning causes git's index to get confused).

Eyvind's proposal is deceptively simple because it simply makes it
much less error prone for users to express something that's already
*technically* possible, but in practice, is very very frequently done
wrong.

Avery