On Fri, May 7, 2010 at 3:16 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html