On Sun, May 23, 2010 at 02:53:18PM +0200, Eyvind Bernhardsen wrote: > On 23. mai 2010, at 13.51, Clemens Buchacher wrote: > > > On Sun, May 23, 2010 at 12:36:51PM +0200, Eyvind Bernhardsen wrote: > >> Yeah, that's what I initially thought too, but it makes sense to > >> be able to use normalization to prevent line ending breakages in > >> your repository. If a file needs CRLFs for some tool to work, > >> you don't want anyone to inadvertently convert it to LF, and > >> "eol=crlf" makes git enforce that. > > > > Unsetting crlf/text already disables converting it to LF. The user > > would have to change the line endings in his work tree and commit > > the file with wrong line endings. I do not see how this can happen > > inadvertently. > > That's because you don't use (or work with people who use) > editors that mangle line endings without asking. That I can imagine. But due to their change, the file will not work any more, not even on their own platform. What did they even make the change for then? > I don't have strong feelings about the need for this feature, but > it has been requested so it's probably useful. Just because a feature is requested doesn't mean it's useful, or even harmless. This has nothing to do with version control in the first place, so I do not see why we should suffer the additional complication. > > No, I am aware of autocrlf=input, but apparently I did not > > understand the meaning of eol=lf correctly. So if a file has CRLF > > endings in the repository, and eol=lf, it will _not_ be converted > > to LF in the work tree? Conversely, if it has LF endings in the > > repository, and eol=crlf, it _will_ be converted to CRLF in the > > work tree? > > That is correct, but "eol=lf" means that the file _should_ be > LF-only in the repository. If it isn't, the repository is > "corrupted". Such a file is marked as dirty when it is checked > out and will be normalized to LF-only line endings when it is > committed, at which point the repository will be fixed. 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. 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. 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? 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. > 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. 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