On Sun, May 23, 2010 at 12:36:51PM +0200, Eyvind Bernhardsen wrote: > On 23. mai 2010, at 00.27, Clemens Buchacher wrote: > > >> The "eol" attribute is used for files that need a specific line > >> ending. Setting it also sets "text". > > > > If a file needs specific line endings, why enable conversion for > > this file at all? Just make sure the repository contains the > > correct version and unset the crlf attribute. > > 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. > > I do see the value of a global core.eol option, however, since it > > allows me to convert to LF instead of CRLF, which AFAIK is not > > currently possible. > > Actually, since git normalizes to LF, "eol=lf" simply means > "convert on input but not on output", which is what > "core.autocrlf=input" currently does. The fact that you didn't > know this reflects the poor usability of core.autocrlf, which is > one of the things this series is trying to rectify :) 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? I was expecting eol=lf and eol=crlf to be symmetric, which is also the reason for my reply to Finn's safe crlf patch. -- 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