On Thu, 13 May 2010, Eyvind Bernhardsen wrote: > > Do you agree that "native" eol should only be CRLF if autocrlf is true? Not really. We're trying to get _away_ from .gitattributes depending on autocrlf, aren't we? > Otherwise, if .gitattributes looks like this: > > *.txt text > > git will put CRLFs in .txt files but LFs in .c files, and I don't think > that makes much sense. Well, but that's what you asked for, isn't it? And I don't see why you say *.c files would have LF's, since that depends on what you put in them: and under Windows, that might well be CRLF. And I do think it's perfectly reasonable to override the "native" mode in your .git/config. If we're renaming the attributes, we might as well then introduce a [core] eol=lf to set the "native" EOL for that repo, exactly because presumably a number of Windows people would like to see the saner LF-only model rather than the traditional native CRLF. In fact, maybe it would even make sense to just make LF the default "native" end-of-line sequence even on windows, so that Windows people who actually want CRLF would have to set core.eol=crlf. Whatever. That would be for the Windows git users to fight out, I don't care. But if we are going to clean up text attribute handling, then I really think we want to totally break that old "core.autocrlf" dependency. Linus -- 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