From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Wed, 01 Jun 2016 08:57:08 GMT
Subject: Re: git gc and worktrees
Message-ID: <574EA364.60408@alum.mit.edu>
In-Reply-To: <20160531221415.GA3824@sigill.intra.peff.net>

On 06/01/2016 12:14 AM, Jeff King wrote:
> [...]
> 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.

That's correct. `for_each_reflog()` does its work by walking the
directory tree under `$GIT_DIR/logs`. So when run in the main
repository, it never looks at the per-worktree reflogs. Therefore,
objects that are only reachable from per-worktree reflogs can end up
getting pruned.

This is closely tangled up with my ref-iterators patch series (which is
why I noticed it), especially with

    [PATCH 13/13] for_each_reflog(): reimplement using iterators

[1].

I think reference stores are going to need two distinct types of
reference iteration: one to iterate over the *logical* reference space
of a single repo or worktree, and one to find all *local* references
and/or reachability roots (e.g., when run within a linked repo). The
current approach, where subtrees of the reference namespace are pasted
ad-hoc into each other partly by manhandling the ref_cache and partly
via the hack in `git_path()` is not, I think, a very good long-term design.

I'd prefer the elementary operation on a low-level reference store to be
iterating over all of the references that are stored locally, and to use
`merge_ref_iterator` for pasting together the parts of low-level
reference stores that are needed to form a logical view of the
references in a linked repo.

Michael

[1]
http://thread.gmane.org/gmane.comp.version-control.git/295860/focus=295866