> 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/<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? > > 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.
