git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Repo corrupted somehow?

From
Eyvind Bernhardsen <eyvind-git@orakel.ntnu.no>
Date
Nov 5, 2008, 12:26 UTC
Message-ID
<77005B51-0170-42EC-BBA7-DCF39C7CFC5E@orakel.ntnu.no>
In-Reply-To
<alpine.LNX.1.00.0811050043030.19665@iabervon.org>
On 5. nov.. 2008, at 06.56, Daniel Barkalow wrote:
Show 13 quoted lines
> 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
Previous: Daniel BarkalowNext: Andrew Arnott
Message 8 of 9 in “Repo corrupted somehow?”
  1. Andrew ArnottNov 4, 2008
  2. Andrew ArnottNov 4, 2008
  3. Andrew ArnottNov 4, 2008
  4. Jeff KingNov 5, 2008
  5. Daniel BarkalowNov 5, 2008
  6. Andrew ArnottNov 5, 2008
  7. Daniel BarkalowNov 5, 2008
  8. Eyvind BernhardsenNov 5, 2008
  9. Andrew ArnottNov 8, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.