Re: [PATCH v3 2/8] Add a place for (not) sharing stuff between worktrees

From: Duy Nguyen <pclouds@gmail.com>
Date: Oct 29, 2018, 17:18 UTC
Message-ID: <CACsJy8Bkjw-T4Aeb8WfdOcjr5OB4HdG1SFYJ9Sokt2JNc2fnOQ@mail.gmail.com>
In-Reply-To: <xmqqin1uwqo6.fsf@gitster-ct.c.googlers.com>

On Mon, Oct 22, 2018 at 6:28 AM Junio C Hamano <gitster@pobox.com> wrote:

Show 26 quoted lines

> > When multiple worktrees are used, we need rules to determine if
> > something belongs to one worktree or all of them. Instead of keeping
> > adding rules when new stuff comes (*), have a generic rule:
> >
> > - Inside $GIT_DIR, which is per-worktree by default, add
> >   $GIT_DIR/common which is always shared. New features that want to
> >   share stuff should put stuff under this directory.
> >
> > - Inside refs/, which is shared by default except refs/bisect, add
> >   refs/worktree/ which is per-worktree. We may eventually move
> >   refs/bisect to this new location and remove the exception in refs
> >   code.
> >
> > (*) And it may also include stuff from external commands which will
> >     have no way to modify common/per-worktree rules.
>
> OK.  Establishing such a convention is a good role for the core-git
> should play to help third-party tools.
>
> Should this play well with the per-worktree configuration as well?
> Is it better to carve out a configuration variable namespace so that
> certain keys are never read from common ones (or per-worktree ones),
> so that people can tell which ones are what?  I know your current
> design says "this is just another new layer, and the users can hang
> themselves with this new rope".  I am wondering if there is a need
> to do something a bit more structured.

I actually find the layered design of config files more elegant. Even before config.worktree is added, the user has system/per-user/per-repo places to put stuff in. "git config" gives control to read or write from a specific layer. We have to add layers to $GIT_DIR/refs to handle multiple worktrees, but since the "API" for those don't have the concept of layers at all, we need a single view where items from different worktrees are accessible via the same path/ref name.

Adding variable namespace in config files does not look easy either. Suppose we have perWorktree.* section just for per-workree stuff, what do we do when the user just do "git config -f not-per-worktree-file perWorktree.something foo" (or --global instead of -f)? What we could do (and already do for some config keys) is ignore perWorktree.* unless they come from config.worktree. Which does help a bit, but not really perfect.

And a namespace like this means the user cannot have subsections anymore (e.g. perWorktree.group.<name>.var is not supported if I remember correctly). So yeah... perhaps we should wait a bit and see what the user (or third party tool makers) comes up with.

-- 
Duy