Re: gc and repack ignore .git/*HEAD when checking reachability

From: Jeff King <peff@peff.net>
Date: Jul 12, 2016, 15:26 UTC
Message-ID: <20160712152646.GF613@sigill.intra.peff.net>
In-Reply-To: <alpine.DEB.2.20.1607121243470.6426@virtualbox>

On Tue, Jul 12, 2016 at 12:47:06PM +0200, Johannes Schindelin wrote:

Show 13 quoted lines

> > Not so fast; it cuts both ways.
> > 
> > People who want multiple worktrees with branches checked out to work
> > in would want to do per-worktree things like bisection, which needs
> > tons more state than we'd be comfortable having directly under
> > $GIT_DIR (e.g. they may also want "git merge" or "git pull", which
> > would use MERGE_HEAD and FETCH_HEAD that are per-worktree and not
> > under refs/; "git bisect" would want to mark number of commits to
> > denote the perimeter of the area of the history being bisected and
> > they live refs/bisect/).
> 
> Sure, `git bisect` would need to realize that it is running in a worktree
> separate from the original one and use a different ref.

I am mostly a bystander in all of these worktree discussions, but your comment here makes a lot of sense to me. We currently have a global ref namespace, but the current proposals seem to want to slice it on invisible lines into per-worktree and global bits, where "refs/bisect" is no longer a global name. But we could also retain a global view, and just let worktrees carve out their own portion of the namespace ("refs/worktree/foo/bisect", or even organize it by application area, "refs/bisect/foo/bad", etc).

Besides being conceptually simpler in the code (global reachability Just Works, because you see all of the refs), it would also let you access individual refs between worktrees if you wanted. So for example, if you are bisecting in worktree "foo", you can access its results from another worktree with "git show bisect/foo/bad".

Likewise for other per-worktree items. If we used refs/MERGE_HEAD and refs/worktree/foo/MERGE_HEAD, then you could access them independently by using the fully qualified names.

The only downside I see is that the existing names are sometimes well-known. I wonder if we could simply add:

  refs/worktree/<your-worktree>/%s

to the dwim ref-lookup when a command is running in a worktree.

-Peff