Re: Repo corrupted somehow?

[Eyvind Bernhardsen <eyvind-git@orakel.ntnu.no>]

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