On Mon, May 24, 2010 at 11:11:40PM +0200, Eyvind Bernhardsen wrote: > If you later discover that you want normalized text files in your > repository, you _will_ have to convert all your files. That's a > bit tricky, but it's not the huge problem you're making it out to > be, and it only has to be done once. I am not just making this stuff up. These things have bitten me in the past, and there have been complaints about it in #git. And even after finding the solution I always felt like crlf handling in git was really broken. I was hoping that after enabling the new eol handling, these weird effects would go away, but obviously they don't. Maybe for you it does not seem like such a big deal, because you are now so familiar with the inner workings of this algorithm. But to a naive user like me it is very counter-intuitive. I am not saying that the new features are all wrong. Some of them really are a major improvement. My main point is that it is still confusing and that in itself will cause issues for many people. And I don't see why we cannot do better. In the first scenario of my previous post (no attributes set), since I already enable core.eol = lf, couldn't we handle that as if text=auto were set on every file? Isn't that what core.autocrlf = true means in this case? And once we normalized the file to LF, why don't we also checkout that version, or at least mark it as dirty in the index, so a reset --hard will fix it up? Regards, Clemens -- 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