From: Stefan Beller Date: Wed, 16 Jan 2019 22:06:24 GMT Subject: Re: [PATCH 01/10] doc: about submodule support with multiple worktrees Message-ID: In-Reply-To: <20190116103159.9305-2-pclouds@gmail.com> > The third problem is a big and complicaed one. Submodule clones complicated > (inside the superproject) are per-worktree. So if you have two > worktrees, and these have one submodule, you need space for _two_ > clones. This is definitely not elegant. The tenative plan is to move tentative? > 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/ (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? > > 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? > Another good point about this approach is we could finally safely > allow "git worktree remove" to work with submodules. With current > solution, removing $GIT_COMMON_DIR/worktrees/X directory means also > removing potentially precious clones inside the "modules" subdir. yup, very sensible. I like this approach very much.