From: Andreas Ericsson <ae@op5.se>
Date: Thu, 11 Jan 2007 13:40:41 GMT
Subject: Re: tree corrupted on disk quota full
Message-ID: <45A63E59.7030009@op5.se>
In-Reply-To: <20070111125726.GJ1759@mellanox.co.il>

Michael S. Tsirkin wrote:
> I hit a quota limit on a disk my tree was on, but did not notice.
> Doing git pull on a tree seems to have corrupted it.
> Now I have:
> 
> $ git-fsck-objects
> error: 4d4d30be967d3284cbf59afd4fba6ab536e295f5: object not found
> error: c03590b581d51d5fa43adbef9415e935d0229412: object not found
> missing tree 10147d79b2418168d9433067b6439971bd4f1261
> broken link from  commit 322a6c93ad86d2a151dd97a4c6b0e014a4893437
>               to    tree 10147d79b2418168d9433067b6439971bd4f1261
> dangling commit 322a6c93ad86d2a151dd97a4c6b0e014a4893437
> 
> The tree can not be pulled into, or from.
> 

Can you do a "git rev-list" on the commit pointing to this tree? If so, 
you should be able to do "git reset HEAD~1" and re-do the fetch.

Otoh, this is curious. Aren't tree- and blob-objects written to disk 
before the commit object pointing to them? If not, how can we claim to 
support atomic commits? I imagined things were written in this order

	blob -> tree -> commit

seeing as the dependency chain goes the other way.

"git repair" could easily be cooked up by finding the first complete 
commit and resetting current HEAD and all branches pointing to it to 
that first complete commit. Issuing a fresh "fetch" after that should 
automagically fix everything for you.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231