On Mon, May 24, 2010 at 2:12 PM, Dmitry Potapov <dpotapov@xxxxxxxxx> wrote: > 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 thought the original motivation behind this change was to make repos with CRLF-textfiles work without reporting diffs on all lines when autocrlf was enabled. Because checking in CRLF-files DOES happen, and for some of us the reality is that we have to deal with such repos. Perhaps I'm confusing this discussion with some other, though. -- Erik "kusma" Faye-Lund -- 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