On 24. mai 2010, at 11.49, Clemens Buchacher wrote: > With CRLF file in the repository, core.autocrlf=true and > core.eol=lf, I tested the patches currently in pu (0ed6711a) in the > following three scenarios: > > 1. no attributes are set > 2. text attribute is set or auto > 3. eol attribute is set to lf > > In the first scenario, the behavior is completely asymmetric. LF > files will be converted to CRLF, if core.eol=crlf, but CRLF files > will _not_ be converted to LF, even if core.eol=lf. And it will not > be marked as dirty either. Yet this is the default behavior in > terms of attributes. Default in terms of attributes maybe, but not in terms of configuration (you need to explicitly set core.eol to lf to see this). But I see your point, core.autocrlf just doesn't work very well unless you want CRLFs. > The only justification I can think of for this behavior is the fact > that on platforms with LF line endings, most tools can deal with > CRLF line endings. Not very convincing. Well, without "safe autocrlf", this would have worked as you expected, marking files as dirty and converting on checkin. Unfortunately, without "safe autocrlf", core.autocrlf just doesn't work in practice, PRECISELY because the person with core.autocrlf set has to clean up after everybody else. > In the second scenario, the file is marked as dirty. Neither reset > --hard nor checkout HEAD . fix the problem. The file has to be > added and committed, after which the line endings are _still_ CRLF. > This appears to be the old autocrlf=true behavior. Is this > intentional? Yes, since it uses the old autocrlf implementation. The documentation states that you need to convert your repository when enabling normalization, but is this going to be big problem in practice? Perhaps the working directory file should be converted to LF, but when? When it is added? When it's committed? If you checkout -f after you commit the change, the file should have the correct line ending, because then it is normalized in the repository and git knows what to do with it. > The third scenario is similar to the second scenario, only it warns > me about CRLF conversion during add and commit. The file still ends > up having CRLF line endings in the work tree. git reset --hard does > not fix the line endings. touch'ing the file finally makes git diff > notice that the file is dirty, but git status still does not list > the file. > > So to me, end of line conversion is still as confusing as it gets. All of your confusion seems to stem from starting with a repository that is not normalized and adding normalization to it. Yes, that is a pain, but there is no way to avoid that, and there is a recipe for fixing it in the documentation. >> This should only be a problem if you set the "text" or "eol" >> attributes in an existing repository, or if someone adds CRLFs to >> a normalized file using an older version of git. > > In other words, this will be a problem all the time, since by > default people will not even know about text or eol. By default people will not enable core.autocrlf either. I just don't see the huge problem here. If your repository does not need normalization, _good_! Nothing will ever be normalized or converted. If somebody wants to work on that repository but prefers CRLFs, they can enable core.autocrlf, and it will work sanely (thanks to "safe autocrlf"), converting text files that can safely be normalized back but leaving all other files alone. 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. -- 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