On Fri, 14 May 2010, Eyvind Bernhardsen wrote: > 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. The thing is, I disagree with your notion of "safe autocrlf". I think it's ugly, and I don't think it's safe at all. It adds a _feeling_ of safety that isn't actually safe. In short: - core.autocrlf is _always_ dangerous. Your "safe" thing isn't any safer at all, since it depends on something that isn't reliable (previous state). Example: new binary files, or changed files, or renames. - so if you want text conversion, but you want it to be truly safe, and only happen for certain files, YOU MUST NOT ENABLE autocrlf. - Ergo: if you make the .gitattributes behaviour depend on autocrlf, you're still screwed, and you've not actually improved on anything at all in the end. It's really that simple. I think "autocrlf" actually works pretty well, but at the same time, I think we made mistakes in the initial design. Let's not make them again. 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