Re: tree corrupted on disk quota full
- From
Linus Torvalds <torvalds@osdl.org>
- Date
- Jan 11, 2007, 18:31 UTC
- Message-ID
- <Pine.LNX.4.64.0701111023090.3594@woody.osdl.org>
- In-Reply-To
- <20070111125726.GJ1759@mellanox.co.il>
On Thu, 11 Jan 2007, Michael S. Tsirkin wrote:
Show 14 quoted lines
> > 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.
That's nasty, but something as simple a "git reset --hard ORIG_HEAD" should fix it (of course, if the disk-full happened earlier, or you've done some other reset or something else that over-write your ORIG_HEAD, you'd need to find the most recent commit that wasn't broken).
The good news is that there's no way your old data got corrupted. You just need to _find_ it (and normally ORIG_HEAD points to it, so it's trivial to find).
The suggestion to use "HEAD~1" is *not* a good one, simply because the pull (if it was a fast-forward) will not have HEAD~1 as your previous head: it will depend on how many commits you pulled. If you had reflog enabled, a "HEAD@{1}" might have worked (or "HEAD@{2}" as you already did the "git reset").
That said, clearly something didn't check the error return of a write() call. Some of that got fixed up recently, so it might even be fixed in current git already.
The most likely case (for a pull) is "git-unpack-objects", I guess.
Linus