On Fri, May 7, 2010 at 4:06 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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 -- 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