Re: Repo corrupted somehow?

> On 5. nov.. 2008, at 06.56, Daniel Barkalow wrote:
>
>> On Tue, 4 Nov 2008, Andrew Arnott wrote:
>>
>>> It was the CRLF conversion.  When I played around with
>>> git config --global core.autocrlf true/false
>>> I got the problem to eventually go away.
>>>
>>> Thanks for all your responses.
>>
>> It's still worth debugging further, because git should know that it wrote
>> the files differently and not see that as changes. It's not too helpful to
>> have autocrlf if it causes this problem.
>
> I think I know what this is.  If a repository contains files with CRLFs,
> those files will show as modified when core.autcorlf is true (if you commit
> them, the CRLFs will be converted to CRs in the repository, so in a sense
> they _are_ modified).  Try turning autocrlf back on, cloning the repository,
> then touching all the files (to make git check them for changes) and see if
> you get the same problem.
>
> I proposed an alternative autocrlf implementation on the list a while back:
> making it an attribute instead of a configuration setting and adding a
> configuration setting to tell git which line ending is preferred when the
> autocrlf attribute is set.
>
> That would allow you to turn on autocrlf and let git convert all CRLFs to
> CRs in a single commit, thus converting a repository with CRLFs to one that
> can be used with autocrlf in a versioned way.  In theory that lets you check
> out new commits with EOL conversion while old commits will be left alone
> (avoiding the problem you saw), but since .gitattributes is read from the
> working directory and not the tree to be checked out, it doesn't work
> perfectly.
>
> I implemented the easy bit (reading autocrlf from .gitattributes), but for
> various reasons the patch has just been gathering dust in my private git.git
> repo.  Maybe I should dust it off :)
> --
> Eyvind
>
>