Re: how to remove unreachable objects?

From: Jeff King <peff@peff.net>
Date: Sep 20, 2011, 00:51 UTC
Message-ID: <20110920005159.GA1674@coredump.intra.peff.net>
In-Reply-To: <7vfwjs82sc.fsf@alter.siamese.dyndns.org>

On Mon, Sep 19, 2011 at 05:40:03PM -0700, Junio C Hamano wrote:

Show 11 quoted lines

> > Does that work? I had the impression from the documentation that the
> > arguments are purely about the reachability analysis, and that the
> > actual corruption/correctness checks actually look through the object db
> > directly, making sure each object is well-formed. Skimming cmd_fsck
> > seems to confirm that.
> 
> You are right that you may see "corrupt object" for unreachable from the
> tips in the object store, but I was talking more about verifying
> everything that is needed for reachability analysis from the given tips
> can be read, iow, "missing object" errors, lack of which would mean you
> can salvage everything reachable from the refs involved in the traversal.

True. Though one could also do that with "git log", and it would be much cheaper (since each trial you run with git-fsck is going to actually fsck the object db, which is expensive).

I can't help but think the right solution there is something like:

  1. If the corrupted or missing object is a blob or tree, figure out
     which commits reference it with something like:

       a. Create a set B of bad objects (blobs or trees).

       b. For each tree in the object db, open and see if it contains
          any elements of B. If so, add the tree to another set, B'.

       c. If B' is empty, done. Otherwise, add elements from B' to B and
          goto step (b).

       d. For each commit in the object db, open and check the tree
          pointer. If it points to an element of B, then the commit is
          bad.

  2. If the object is a commit, or if you arrived at a set of bad
     commits through step (1), then use "branch --contains" on the
     bad commits.

which is algorithmically efficient (though probably slow if you had to cat-file each tree). It might be a handy special command, though (I have seen people ask for "which part of history references this blob" on occasion). I've never bothered writing it because I've never had a corrupt object. :)

Anyway, that is perhaps not relevant to your point. But I do think that fsck with arguments is more likely to confuse someone than to actually be part of a productive use-case. I have no problem with deprecating or removing it.

-Peff