On Thu, Jan 17, 2019 at 5:06 AM Stefan Beller <sbeller@xxxxxxxxxx> wrote: > > clones from $GIT_COMMON_DIR/worktrees/X/modules to > > $GIT_COMMON_DIR/common/modules. > > ... from the submodule side of things this is big problem, > as the submodule is usually assumed at $GIT_DIR/modules/<name> > (I think we have not been strict in $GIT_DIR $GIT_COMMON_DIR > in the submodule code) > > So the plan is to neither use > > $GIT_COMMON_DIR/worktrees/X/modules/Y > $GIT_COMMON_DIR/modules/Y/worktrees/X > > but to create a new third location at > > $GIT_COMMON_DIR/common/modules > > to which either new submodule worktrees > or superproject worktrees that happen to have this submodule > can point to? Yes. And this is yet another "absorb" operation to move from the current location to the new one. The code will have to check both places, just as it has to check if "foo/bar/.git" is a real repo before it goes to $GIT_DIR/.git/modules/bar (at least this is how I understand it). > > The latter directory is shared across all worktrees. Once we keep the > > clone in a common place, the submodule's worktree can be created and > > managed with git-worktree[1]. > > So even when the user has never heard of worktrees, the internal structure > will be worktree oriented, the common dir in common/modules/Y and in > $GIT_DIR/modules/Y we could just have a worktree git dir? I think the .git dir will be in common/modules/Y. $GIT_DIR/modules/Y is basically replaced by $GIT_COMMON_DIR/common/modules/Y, which should work even when you don't use git-worktree (in single-worktree setting, $GIT_COMMON_DIR == $GIT_DIR). -- Duy
