On Tue, 13 Feb 2007, Mark Levedahl wrote: > > A proper win32 port will accept any of \n, \r\n as valid line endings (add > \r to support Mac pre-OSX if anyone cares, I still occasionally see such > files), treat any of them as semantically equal, and enforce the user's > chosen style (\n or \r\n) on output. The patch I sent out does that, except right now the "autocrlf" flag is just a pure boolean. I could easily make it take a ternary value: - off (normal UNIX semantics - never change anything) - on (turn CRLF->LF on input, turn LF->CRLF on output) - input-only (turn CRLF->LF on input, leave LF alone on output) that would be just a couple of extra lines (almost all of them in the config file parsing logic). [ The "output-only" case is obviously possible, but insane. It would turn a LF-only file into CRLF on output, and then not turn it back on input, so doing any "git commit -a" would basically turn every single lines into CRLF, which you do NOT want. So hopefully that explains the three - not four - cases ] And the patch already leaves files that the user doesn't touch alone (ie if you check something out with CRLF turned off, and then turn it on in the config, nobody will care - the checked-out copy will have LF-only even if explicitly re-checking it out would turn it into CRLF, but that's fine. It would be interesting to hear if the patch works for the MinGW people in particular. People using git with a Cygnus environment are probably used to try to keep files with just LF, since they are really trying to do a UNIX environment on top of Windows. But I suspect that WinGW people are more likely to use native Windows tools for things, and then perhaps just a smattering of UNIXy tools.. Linus - 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