Re: CRLF problems with Git on Win32

[Dmitry Potapov <dpotapov@gmail.com>]

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