On 13. mai 2010, at 23.45, Linus Torvalds wrote: > 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? I'm not sure we still are. I certainly was when I started this series, but that was because autocrlf just plain didn't work with many existing repositories. When "safe autocrlf" fixed that, I decided that the extra complexity of core.eolStyle wasn't worth it. I could be wrong, and I'd be happy to add it later. I don't think this series requires it, though. I'd like to make my terms explicit: when I say "core.autocrlf", I mean a config value that makes git normalize all text files automagically. "core.eol" would be a different config value that simply tells git what line endings to put in files that are explicitly flagged as "text" (or automatically detected by "text=auto"). >> 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. That's not an interesting problem. If you're okay with CRLFs in your repository there's no need for you to use text file normalization at all, and you're certainly not going to bother to set any text attributes. Everything will Just Work. To make it more relevant, let's consider what would happen if you suddenly wanted to share that repository with a Linux user. You would clearly have been better off if the text files had been normalized, but I can only see three ways this could happen: 1. You set "* text=auto" when you created the repository 2. text=auto is the default for all files 3. autocrlf=true is set by default on Windows The first option is unrealistic, and we probably agree that the second one is a bad idea. That's why, once Finn Arne fixed autocrlf, I realized it's not all that bad. > 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. But they can equally easily set "core.autocrlf=false". Although the name still grates. > 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. This is the crux of the problem. It's possible that I'm just being prejudiced, but I think that if someone wants CRLF as a _default_ they probably want it to be the default for all text files, not just normalized ones. > 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. "core.autocrlf=true" is exactly equivalent to "core.eol=crlf" in a repository with "* text=auto" (setting the "text" attribute disables the index check). In a repository that doesn't care, "core.autocrlf=true" will normalize your text files and put CRLFs in them, while "core.eol=crlf" won't do a thing. Unless you're simply arguing for renaming autocrlf to eol? -- Eyvind -- 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