Re: CRLF problems with Git on Win32

[Dmitry Potapov <dpotapov@gmail.com>]

On Tue, Jan 08, 2008 at 07:58:57PM +0100, Steffen Prohaska wrote:
> 
> I don't think a solution will be found by declaring one platform
> native (UNIX) and all other platform non-native.  The question to
> answer is how to support cross-platform projects.  A valid
> solution should never corrupt data unless the user explicitly
> told git to do so.  I don't believe it is a valid solution to set
> core.autocrlf=true on Windows and tell the users: "Well, in its
> default settings, git sometimes corrupts your data on Windows.
> Maybe you want to switch to Linux because this is the native
> platform where data corruption will never happen."

Maybe I am wrong but it seems to me that to guarantee that
CRLF conversion is reversible (which means that you can
always get exactly what you put into the repository), it is
enough to check that the conversation is performed only if
every LF is preceded by CR. If it is not so, error out and
tell the user that the file should be either marked as binary
or EOL in the text must be corrected.

So, even in those rare cases where the heuristic went wrong,
you will not lose your data. Most likely you will get the
above error, but even if a binary file is checked in as text,
it will affect only cross-platform projects, and it will be
easily to correct the situation later by marking this file
as binary and checking in again. So, it is a extermely rare
event, and no data is lost.

Perhaps, this option can be called core.autocrlf=safe

IMHO, a _text_ file is not just some octets, it consists of
lines. Even without CRLF conversation, Git is aware about
to do some basic operations like diff and merge. So, it is
natural to store lines in the repository in the same EOL
marker regardless on what platform the file is created. So,
having core.autocrlf=false on Windows is wrong. You may not
notice it until you do not move to another platform, but the
whole thing is already broken. It is not about one platform
being more native than other. It is like in the C standard,
LF is used to denote the end of line, because it is the only
sane choice to mark it.

Dmitry