Re: Problem with pack

Andreas Ericsson [off-list ref] writes:

quoted

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?