Re: [PATCH 01/10] doc: about submodule support with multiple worktrees
- From
Stefan Beller <sbeller@google.com>
- Date
- Jan 16, 2019, 22:06 UTC
- Message-ID
- <CAGZ79kYWi0EDr-XvoXm=-Oo-_9FiieNHbWzA5o8TiirLw+xXBg@mail.gmail.com>
- 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/<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.