Re: [BUG] attribute "eol" with "crlf"

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 16, 2011, 21:21 UTC
Message-ID: <7vmxasgqlm.fsf@alter.siamese.dyndns.org>
In-Reply-To: <vpqr504wf70.fsf@bauges.imag.fr>

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

Show 27 quoted lines

> Ralf Thielow <ralf.thielow@googlemail.com> writes:
>
>> There's a bug in git-1.7.8 if you use the attribute "eol" with "crlf".
>>
>> Steps to reproduce:
>> - add and commit a text file which uses 0d0a for line breaks
>> 7465 7374 0d0a 0d0a 7465 7374 0d0a       test....test..
>> - add ".gitattributes" with "*.txt eol=crlf"
>> - change a line in the file
>> - execute "git checkout [file]"
>>
>> The result is:
>> 7465 7374 0d0d 0a0d 0d0a 7465 7374 0d0d  test......test..
>
> It seems to me to be the expected behavior. You committed a file whose
> line endings are not normalized to LF in the repository, and asked for a
> conversion LF -> CRLF on checkout, which Git did.
>
> Git can't know exactly the moment when you edit .gitattributes, so it
> can't do the conversion at the time you add the eol=crlf attribute. It
> does it on checkout.
>
>> 0d0a was replaced by 0d0d0a.
>
> I'd say 0a (LF) was replaced by 0d0a (CRLF).
>
> What behavior would you have expected?

The sequence adds "test\r\n" file without .gitattributes to have the repository record that exact byte sequence for the file. But then later goes around and says "This file wants to express the end of line with CRLF on the filesystem, so please replace LF in the repository representation to CRLF when checking out, and replace CRLF in the working tree to LF when checking in".

So it is not surprising that "\r\n" coming from the repository is replaced to "\r\r\n" when checked out. As far as the repository data is concerned, that line has a funny byte with value "\r" at the end, immediately before the line terminator "\n".

What you said is _technically_ correct in that sense.

However, I think the CRLF filter used to have a hack to strip "\r" if the repository data records "\r" at the end of line. This was intended to help people who checked in such a broken text file (if it is a text file, then raw ascii CR does not have a place in it in the repository representation) and it was a useful hack to help people recover from such mistakes to start the project from DOS-only world (with CRLF in the repository data) and migrate to cross platform world (with LF in the repository data, CRLF in the DOS working tree). I suspect that the streaming filter conversion may not have the same hack in it.