Re: possible gitattributes eol bug with new eol=crlf | lf support?

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

 



I don't understand the inner workings of .git/index, but is removing
that file destructive to history or anything? What are the
implications of that delete-command?

Bob

On Fri, Sep 10, 2010 at 2:25 PM, Eyvind Bernhardsen
<eyvind.bernhardsen@xxxxxxxxx> wrote:
> On 10. sep. 2010, at 00.31, Robert Buck wrote:
>
> [...]
>
>> Conversion of LF-EOL files to CRLF works fine, but conversion of CRLF
>> to LF fails to occur.
>>
>> The doc is a little unclear if this is expected behavior, which if I
>> recall correctly from the email threads related to the new eol
>> support, this should not have occurred.
>
> Unfortunately, this is expected behaviour: you need to "manually" remove CRLFs when you turn on eol conversion.  The simplest way to do this is "rm .git/index && git reset", then commit the modified files (ideally in the same commit that modifies .gitattributes--this is mentioned in gitattributes(5)).
>
> To make this work as it should, git would have to notice changes to .gitattributes and check files which have had their attributes changed.  It's on my "I wish I had time to do this" list.
>
> - Eyvind
>
>
--
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]