Re: git gc and worktrees

From: Jeff King <peff@peff.net>
Date: May 31, 2016, 22:14 UTC
Message-ID: <20160531221415.GA3824@sigill.intra.peff.net>
In-Reply-To: <CACsJy8BHU0YtgvjuefRPuMPLhvoOPLVMhR4YzH8=wVFeOie+Xw@mail.gmail.com>

On Tue, May 31, 2016 at 07:02:15PM +0700, Duy Nguyen wrote:

Show 24 quoted lines

> On Tue, May 31, 2016 at 2:07 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> > Earlier this year I had a largish merge going on in a separate worktree.
> > With a mix of staged resolutions and unmerged paths in the index, I ran 'git
> > gc' in the main worktree. This removed a lot of objects that were recorded
> > in that separate worktree index. (I was able to recover them because the
> > content was still on disk.)
> >
> > Now I wanted to derive a test case that shows that breakage, but I am unable
> > to. The objects recorded in a separate worktree index, but not committed,
> > yet, are not pruned anymore.
> >
> > Have there been any fixes in this regard recently? Or does this look like
> > something else going on?
> 
> Not sure. I vaguely recall Jeff touched this pruning issue once,
> something about recent objects will not be pruned based on mtime. But
> maybe some of those objects in the index are not so young, and because
> I think we never check indexes in git-gc/git-prune, they have a chance
> to be deleted.
> 
> No I'm wrong. mark_reachable_objects() which is used by git-prune,
> does add objects from index and HEAD, which only covers those from
> _current_ worktree. This should be fixed even if it is not the root
> cause of your problem. I'll look into it.

Right, we use the index for reachability checks (both in "prune", but also during a "repack -a", which uses the revision parser's '--indexed-objects" option). That obviously should handle per-worktree index files, but I don't know whether it currently does.

Michael (cc'd) noted to me off-list recently that there may be some special cases there regarding reflogs in other worktrees (i.e., that we don't always include them for our reachability checks). I don't know the details, though.

The "recent object" stuff you're thinking of is that we will keep a non-recent object X if it is referenced (directly or indirectly) by another object Y that _is_ recent, but not otherwise reachable. That should work independent of worktrees, because it finds the recent objects directly in the object database, and then walks their graphs (but it could indeed make writing tests a little trickier, as it may be harder to convince some objects to get pruned in the first place).

-Peff