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

From: Avery Pennarun <apenwarr@gmail.com>
Date: May 7, 2010, 19:35 UTC
Message-ID: <i2i32541b131005071235z64c9de56w29a2d555cf801c9a@mail.gmail.com>
In-Reply-To: <alpine.LFD.2.00.1005071213550.901@i5.linux-foundation.org>

On Fri, May 7, 2010 at 3:16 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:

Show 12 quoted lines

> 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