Re: Problem with pack

From: Junio C Hamano <junkio@cox.net>
Date: Aug 25, 2006, 10:58 UTC
Message-ID: <7vbqq95bfq.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <44EECEDC.7090608@op5.se>

Andreas Ericsson <ae@op5.se> writes:

Show 9 quoted lines

>> Btw, even without that, if I understand correctly, git packs are
>> collections of compressed objects, each of which has its own header
>> stating how long is the compressed object itself. In my case, the
>> error is in inflating one object (git unpack-objects says inflate
>> returns -3)... so shouldn't there be a way to try to skip to the
>> next object even in this case?
>
> It should be possible, assuming the pack index is still intact. The
> pack index is where the headers are stored, afaik.

The problem Sergio seems to be having is because somehow he does not have a base object that another object that is in the pack depends on, because the latter object is stored in deltified form.

This should never happen unless .pack itself is corrupted (git-pack-objects, unless explicitly told to do so with --thin flag to git-rev-list upstream, would not make a delta against objects not in the same pack).

When a delta is written to the pack file, unless its base object has already written out, git-pack-objects writes out the base object immediately after that deltified object. So one possibility is that the pack was truncated soon after the delta that is having trouble with finding its base object. In such a case, the proposed recovery measure of skipping the corruption and keep going would not buy you that much. On the other hand, if the corruption is in the middle (e.g. a single disk block was wiped out), having .idx file might help you resync.

Does the pack pass git-verify-pack test, I wonder?