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

From: Duy Nguyen <pclouds@gmail.com>
Date: Feb 7, 2017, 15:07 UTC
Message-ID: <CACsJy8CYrbSJqbG7h+-wQPNBCNAVs94Hx7m8qXXb88L0o-rw0Q@mail.gmail.com>
In-Reply-To: <CACsJy8CHoroX2k9GqOFmXkvvPCPN4SBeCg+6aC2WSWNSKVmWQw@mail.gmail.com>

On Thu, Jan 19, 2017 at 6:55 PM, Duy Nguyen <pclouds@gmail.com> wrote:

Show 6 quoted lines

> 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).

It just occurs to me that, since the refs directory structure of a linked worktree is exactly like one in a normal single-worktree setup, minus the shared (or packed) refs. The "files" refs backend can just see this "per-worktree only" refs directory as a remote refs storage, which is just another name for "submodule".

So, we could just use the exact same submodule code path in refs to create a per-worktree refs storage. Doing it this way, files backedn do not need to learn about linked worktrees at all. To retrieve a per-worktree refs storage, we do "get_ref_store(".git/worktrees/foobar")". To get all per-worktree refs do for_each_ref_submodule(".git/worktrees/foobar", ...).

Does it make sense? Should we go this way?

-- 
Duy