Re: CRLF problems with Git on Win32

From: Steffen Prohaska <prohaska@zib.de>
Date: Jan 7, 2008, 21:40 UTC
Message-ID: <3B08AC4C-A807-4155-8AD7-DC6A6D0FE134@zib.de>
In-Reply-To: <alpine.LSU.1.00.0801072115120.10101@racer.site>

On Jan 7, 2008, at 10:18 PM, Johannes Schindelin wrote:

Show 22 quoted lines

> Hi,
>
> [msysGit Cc'ed, since it is massively concerned by this thread]
>
> On Mon, 7 Jan 2008, Robin Rosenberg wrote:
>
>> måndagen den 7 januari 2008 skrev du:
>>> Problem.  There is not a single "right".  It really depends on the
>>> project.
>>
>> Indeed, but the most common SCM's detect binary files automatically,
>> either by suffix or content analysis, so I think that is what user's
>> expect. It will be right for more projects than the current  
>> behaviour.
>
> Steffen also fought for turning this on by default, but so far I  
> resisted.
> For a good reason: the primary user of msysGit for the moment is...
> msysGit.  And this project does not need CR for obvious reasons.
>
> But I imagine that it makes sense for the Git installers.  Colour me
> no-longer-resisting.

Eventually I gave in and even voted for "Git does not modify content unless explicitly requested otherwise".

Here's the full discussion:

http://code.google.com/p/msysgit/issues/detail?id=21

I believe the main question is which type of projects we would like to support by our default. For real cross-platform projects that will be checked out on Windows and Unix we should choose "core.autocrlf true" as our default. But if our default are native Windows projects that will never be checked out on Unix, then we should not set core.autocrlf by default.

I once fought for "real cross-platform", because this is what I need in my daily work. Note, however, that this setting bears the slight chance of git failing to correctly detect a binary file. In this case git would corrupt the file. So there is a tiny chance of data loss with "core.autocrlf true". The safest choice is to leave core.autocrlf unset.

	Steffen