Re: The design of refs backends, linked worktrees and submodules

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 19, 2017, 20:04 UTC
Message-ID: <alpine.DEB.2.20.1701192057530.3469@virtualbox>
In-Reply-To: <341999fc-4496-b974-c117-c18a2fca1358@alum.mit.edu>

Hi,

On Thu, 19 Jan 2017, Michael Haggerty wrote:

Show 27 quoted lines

> On 01/19/2017 12:55 PM, Duy Nguyen wrote:
> > I've started working on fixing the "git gc" issue with multiple
> > worktrees, which brings me back to this. Just some thoughts. Comments
> > are really appreciated.
> > 
> > In the current code, files backend has special cases for both
> > submodules (explicitly) and linked worktrees (hidden behind git_path).
> 
> There is another terrible hack also needed to implement linked
> worktrees, namely that the `refs/bisect/` hierarchy is manually inserted
> into the `ref_cache`, because otherwise it wouldn't be noticed when
> iterating over loose references via `readdir()`.
> 
> Other similar hacks would be required if other reference subtrees are
> declared to be per-worktree.
> 
> > But if a backend has to handle this stuff, all future backends have to
> > too. Which does not sound great. Imagine we have "something" in
> > addition to worktrees and submodules in future, then all backends have
> > to learn about it.
> 
> Agreed, the status quo is not pretty.
> 
> I kindof think that it would have been a better design to store the
> references for all linked worktrees in the main repository's ref-store.
> For example, the "bisect" refs for a worktree named "<name>" could have
> been stored under "refs/worktrees/<name>/bisect/*".

That strikes me as a good design, indeed. It addresses very explicitly the root cause of the worktree problems: Git's source code was developed for years with the assumption that there is a 1:1 mapping between ref names and SHA-1s in each repository, and the way worktrees were implemented broke that assumption.

So introducing a new refs/ namespace -- that is visible to all other worktrees -- would have addressed that problem.

This, BTW, is related to my concerns about introducing a "shadow" config layer for worktrees: I still think it would be a bad idea, and very likely to cause regressions in surprising ways, to allow such config "overlays" per-worktree, as Git's current code's assumption is that there is only one config per repository, and that it can, say, set one config setting to match another (which in the per-worktree case would possibly hold true in only one worktree only). Instead, introducing a new "namespace" in the (single) config similar to refs/worktrees/<name> could address that problem preemptively.

Ciao, Johannes