Re: fsck option to remove corrupt objects - why/why not?

From: Jeff King <peff@peff.net>
Date: Oct 16, 2014, 12:25 UTC
Message-ID: <20141016122533.GA8451@peff.net>
In-Reply-To: <CALKQrgda8mVbqP5=Ag8juN9HMQp7iQ9eDJETfRJe1b0taAFGkg@mail.gmail.com>

On Thu, Oct 16, 2014 at 11:04:04AM +0200, Johan Herland wrote:

Show 9 quoted lines

> I simply copied the packfile containing the good copy into the
> corrupted repo, and then ran a "git gc", which "happened" to use the
> good copy of the corrupted object and complete successfully (instead
> of barfing on the bad copy). The GC then removed the old
> (now-obsolete) packfiles, and thus the corruption was gone.
> 
> However, exactly _why_ git happened to prefer the good copy in my
> copied packfile instead of the bad copy in the existing packfile, I do
> not know. I suspect some amount of pure luck was involved.

I'm not sure that it is luck, but more like 8eca0b4 (implement some resilience against pack corruptions, 2008-06-23) working as intended[1]. Generally, git should be able to warn about corrupted objects and look in other packs for them (both for regular operations, and for repacking).

-Peff

[1] That's just one of the many commits dealing with this. Try running
    "git log --author=Nicolas.Pitre --grep=corrupt" for more. :)