On Fri, Jan 11, 2008 at 07:00:40PM +0000, Gregory Jefferis wrote: > > LF only repositories are model that everyone is tending towards but I feel > that there are (sane) people out there who would sometimes like to have CRLF > files in the repository and do cross-platform development (I would > developing on a Mac for a Windows originated Win/Mac project or if I were > keeping vendor source code in a tree). In spite of the plethora of autocrlf > variants so far there is still none that on unix would give you LF->CRLF on > check in and CRLF->LF on checkout! This should be perfectly compatible with > git's internals Git internally considers only LF as the EOL marker. I think there are more three hundreds places in Git where the decision about end-of-line is made based on that. Though CRLF may appear to work, but it is more an artifact caused by its LF ending, so what it actually works is LF and nothing else. IOW, CRLF from the Git's point of view is no better EOL than let's say SPACE+LF. > and I think it should be possible to allow this without > breaking anything for other situations. One solution, which would have > other uses, would be to allow checkin conversion to a specified line ending > and checkout conversion to platform line ending as separately configurable > options. > > If this seems outrageous then it should be made perfectly clear that the git > project strongly discourages CRLF text files in cross-platform repositories, Because LF is the only true EOL marker, and CRLF is not and never will be. In fact, Git is written in C, and the decision of what is EOL in C is made many years ago. So, it is the only sane choice to use LF for _internal_ representation. It can be said that *nix users are lucky in that their OS uses the same symbol, but it is similar to big-endian platforms being lucky with byte order when it comes to TCP/IP. That is not because TCP/IP wants to discourage little-endian platforms, but having the single encoding is the only sane choice if you care about interoperability, and any other decision will end up being much worse. 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
