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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes:

> Ralf Thielow <ralf.thielow@xxxxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]