On Sun, May 23, 2010 at 01:51:27PM +0200, Clemens Buchacher wrote: > On Sun, May 23, 2010 at 12:36:51PM +0200, Eyvind Bernhardsen wrote: > > > > 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? All text files should LF in the repository, if some file does not, it means the repository is corrupted in respect of handling text files. So, the situation is not symmetric at all! I don't know how better to handle this "corruption". I guess, it should be a warning about some files having different ending that it should have had based on their attributes. > > 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. Finn's patch about _automatic_ text detection when there is no explicit policy about what ending this file should have. Dmitry -- 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