On Tue, Jan 08, 2008 at 01:31:57PM -0800, Linus Torvalds wrote: > > but we don't check that there are no "naked" LF characters. But my idea was about checking for "naked" LF, because if there is at least one naked LF, then you will get a _different_ file than you put into the repository. > > So the only thing you'd need to add is to add a > > /* No naked LF's! */ > if (safecrlf && stats.lf) It seems the check for named LF should be: if (safecrlf && stats.lf == stats.crlf) > return 0; Unfortunately, you cannot return 0 here, because if there is no CRLF, the opposite conversation cannot tell apart when all CRLF were successfully converted to LF, and when there was no conversation at all. So, the only thing to do here is to die() saying this file should be either marked as binary or EOL in the text must be corrected. > > to that sequence too, but the thing is, having mixed line-endings isn't > actually all that unusual, so I think that kind of "autocrlf=safe" thing > is actually almost useless - because when that thing triggers, you almost > always *do* want to convert it to be just one way. I agree that in most cases, you *do* want to covert, but the idea of the "safe" mode is to protect you from the possibility (whatever small it is) when you do not want to convert, because it is a _binary_ file, but is_binary heuristic was wrong. > I've seen it multiple times when people cooperate with windows files with > unix tools, where unix editors often preserve old CRLF's, but write new > lines with just LF. > > So "autocrlf=safe" would be trivial to add, but I suspect it would cause > more confusion than it would fix. The idea of "autocrlf=safe" is always to be on the safe side. Those who prefer automatic correction of EOL can use "autocrlf=true". Besides, checking EOL is somewhat similar checking whitespaces. Git allows you either have --whitespace=error or --whitespace=strip, so it is reasonable to have the same choice about EOL. I may choose either the "safe" mode, which will only error out, or I can have the "true" mode, which corrects EOLs on-fly. 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
