"jonsmirl@xxxxxxxxx" <jonsmirl@xxxxxxxxx> writes:
> I just ran git repack on my kernel tree and got these results....
>
> I have all of my work saved in patches so this doesn't really need to
> get fixed, I can just whack the tree and start over. I'm just
> wondering if there is a way to recover from this in case I actually
> had something irrecoverable in the tree. I've probably been using
> this same tree for about six years so it has seen a lot of git
> revisions.
>
> jonsmirl@terra:/home/linus$ git repack -ad
> Counting objects: 2065160, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (462609/462609), done.
> error: inflate: data stream error (invalid distance too far back)
> error: corrupt packed object for 392ad4a422913ecc0eb76caaa6d2d10de0ea1505
> error: inflate: data stream error (invalid distance too far back)
> error: failed to unpack compressed delta at offset 131682613 from
> .git/objects/pack/pack-93e2de1939a33ce0b64fb5bd2c9d9897167ae820.pack
> error: failed to read object 392ad4a422913ecc0eb76caaa6d2d10de0ea1505
> at offset 131682590 from
> .git/objects/pack/pack-93e2de1939a33ce0b64fb5bd2c9d9897167ae820.pack
> Writing objects: 100% (2065160/2065160), done.
> Total 2065160 (delta 1724066), reused 1921643 (delta 1584095)
> jonsmirl@terra:/home/linus$
>
> The corrupt object is probably an ancient object in the kernel tree
> that I don't care about and it is unlikely that I will bump into it.
> But, how do you recover from this?
A delta compressed is so tightly packed that a single-bit error on disk
will propagate through all of the objects that are represented as a delta
against that object. So it won't be very pretty.
> The object is likely at kernel.org.
> Can git go fetch it somehow?
The protocol is designed specifically to disallow "I guessed that the
trade secret is contained within an object whose object name is this,
please feed me that object" kind of requests, so in general no.
If you know a tagged version that is newer than the tree that contained
the problematic object, you could "git fetch $remote_repo $that_tag" into
an empty repository, "git cat-file blob $that_object_name" into a
temporary file, then use "git hash-object -t blob -w $that_temporary_file"
in the repository with the problematic object (it may be a tree, but you
get the idea).
But seeing that your repack succeeded, it may be the case that you already
have the object in a healthy state available from elsewhere to the
repository with this problem. So "git fetch it somehow" is probably not
necessary to begin with. When there is a corrupt object in a pack, but a
good copy of it is available elsewhere (e.g. in a loose form, in another
pack, or available via your .git/objects/info/alternates, we will use the
good copy, ignoring the corrupt one.
One thing I can think of is to do this (assuming /home/linus is the
problematic repository):
$ cd /var/tmp && rm -fr gomi && git init --bare gomi.git
$ cd gomi.git
$ git fetch file:///home/linus 'refs/*:refs/*'
$ cd /home/linus
$ mv .git/objects .git-objects-saved
$ mv /var/tmp/gomi.git/objects .git/objects
$ cp -r .git-objects-saved/info .git/objects/
But note that this will lose objects that are not reachable from the
refs in your original /home/linus repository.
> git fsck isn't happy....
That is not unexpected, but notice that they are all "dangling" and not
corrupt.
--
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