Andreas Ericsson <ae@xxxxxx> writes:
>> 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?
If I try to verify the pack I get:
git verify-pack -v pack-ebcdfbbda07e5a3e4136aa1f499990b35685bab4.idx
fatal: failed to read delta-pack base object
2849bd2bd8a76bbca37df2a4c8e8b990811d01a7
the package length seems reasonable, however... (no evident sign of
truncation, but I haven't looked inside the index to check the exact
positions of objects)...
and git unpack-object dies with error code -3 in inflate...
If I am not wrong (but I might easily be so) this should not be relative
to truncation...
Sergio
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html