On Mon, Oct 22, 2018 at 6:28 AM Junio C Hamano <gits...@pobox.com> wrote: > > 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
