Re: git gc and worktrees

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Jun 1, 2016, 08:57 UTC
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:

Show 5 quoted lines

> [...]
> 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