On 25. mai 2010, at 00.11, Clemens Buchacher wrote: > 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. Sorry, I was in a hurry and shouldn't have been so dismissive. I do think that the new features will help more than they cause trouble, though. [...] > 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? Isn't that just the current core.autocrlf=input behaviour? The reason autocrlf was changed is because it breaks badly on repositories that have text files (ie, files that the autocrlf mechanism wants to normalize) that contain CRLFs in the repository. If you see someone who has problems with autocrlf in #git, it's almost certainly because autocrlf is on by default, they cloned a repository, and now a seemingly random selection of files are dirty and checking them out doesn't help. The "safe autocrlf" patch fixes this by not trying to normalize any files that are not already normalized in the index. This is what you noticed: the files do not show up as dirty and will not have their line endings converted. The tradeoff is that setting "core.autocrlf" no longer normalizes all text files, only new ones and ones that are already normalized. You (rightly) expected line endings to be normalized to LF when core.eol=lf, and I do need to fix that in the documentation. Safe autocrlf _only_ works if you want CRLF line endings in your working directory. A similar feature that converts text files that have CRLF in the repository to LF would need more development. I don't know how many people would use such a feature, and I would solve that problem by setting "* text=auto" and normalizing the repository instead. > 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? I dunno. Won't it be even more confusing that the file is still dirty after you add it? The problem with converting it in the working directory when you add is that it loses information: if you didnt' want that file to be converted, there's no way to revert (this is very bad if it's a file that contained a mix of CRLF and LF). Maybe rewording the "[CR]LF will be replaced by [CR]LF in <file>" warning to tell the user how to get the working directory version normalized would be the best solution. As I said, though, this is a one-time problem: once your repository is normalized and has text attributes set, it will stay normalized. -- 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