Re: CRLF support bugs

[Hannu Koivisto <azure@iki.fi>]

Dmitry Potapov <dpotapov@gmail.com> writes:

> 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.

>> 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