Re: CRLF support bugs

From: Hannu Koivisto <azure@iki.fi>
Date: Nov 3, 2008, 22:24 UTC
Message-ID: <83mygga1o6.fsf@kalahari.s2.org>
In-Reply-To: <20081103164626.GG21650@dpotapov.dyndns.org>

Dmitry Potapov <dpotapov@gmail.com> writes:

Show 5 quoted lines

> On Mon, Nov 03, 2008 at 05:05:24PM +0200, Hannu Koivisto wrote:
>
> core.autocrlf was exactly meant to be set globally. Basically,
> it says what end-of-line should be on your system. It is strange
> to have it different for different repositories.

Maybe so from the point of view of what it was intended for, but since there is nothing else that could be used to control end of line conversion on a repository basis, it certainly doesn't feel strange to me to use it like that.

When you clone & checkout, say, the official git repository on Windows, are you comfortable doing it with core.autocrlf globally set to true? Maybe you know it's fine to do that so you actually are but I'm not. How about some other random free software mainly-Unix project you would like to develop / build under Windows? Even if text vs. binary autodetection worked perfectly (and it doesn't), CRLF line ends may still be the wrong choice for some project. I recall one such project and while admittedly the situation with it may have changed since I last used it, that doesn't change the point.

I certainly wouldn't want to have core.autocrlf globally set to true on Windows. No automatic conversion is a much safer default. I only want CRLF conversion to happen with projects that have actually considered such checkouts and if necessary have been carefully set up to support it by using .gitattributes.

Show 13 quoted lines

>> I also observed this problem:
>> 
>> # Pretend someone does this on Unix
>> mkdir test1
>> cd test1
>> git init
>> echo "*.c crlf" > .gitattributes
>> echo -en "foo\r\nfoo\r\nfoo\r\n" > kala.c
>
> The 'crlf' attribute means that the file should be treated as 'text'
> without applying heuristic. The correct ending for text files on Unix
> is '\n', not '\r\n'.  So, you put a text file with incorrect ending,
> not surprisingly it causes problems for Windows users later.

It seems to me you are looking at this, too, from the technical point of view. Yes, given the way CRLF support is implemented, the end result was expected. But that doesn't mean it was ok from the user's point of view. Consider usability instead. A user makes a mistake and adds a file from a colleague who uses Windows without first converting it. Are you really saying "so he made a mistake, who cares if repository users face problems"? I think it's just very bad usability that by making such a small mistake you cause the system to end up in a state that doesn't make any sense, i.e. git claims you have modifications right after clone & checkout even though you haven't modified anything.

-- 
Hannu