Re: [RFC] worktree: add --recurse-submodules support to git worktree add

[Junio C Hamano <gitster@pobox.com>]

Phillip Wood <phillip.wood123@gmail.com> writes:

> On 15/04/2026 01:14, JAM wrote:
>> Back in 2022, Glen Choo noted [1] that git worktree add leaves submodules
>> unhandled and suggested a --recurse-submodules flag to fix that. The thread
>> went quiet. The 2015–2016 discussions by Duy and Beller [2][3] had flagged a
>> deeper design concern: submodule existence (which worktrees have which
>> submodules checked out) is tangled up with submodule configuration (URL, 
>> path),
>> making per-worktree submodule support tricky to reason about.
>> 
>> This proposal sidesteps that concern entirely. Rather than touching 
>> submodule
>> configuration at all, the idea is to reuse the git object data that's 
>> already
>> present in the main repository — the same thing git worktree add already 
>> does
>> for the top-level object store, extended down to the submodule layer.
>
> I'm not really a submodule user so maybe I'm missing something. 
> Worktrees separate out per-worktree data such as refs like HEAD which 
> are stored under the worktree's gitdir in 
> "$GIT_COMMON_DIR/worktrees/$id" and per-repository data such as the 
> object store which is stored under "$GIT_COMMON_DIR". The proposal below 
> appears to use the same modules directory for each worktree so if I have 
> two worktrees A and B each with a submodule "sub" how can I checkout 
> commit C1 in "A/sub" and commit C2 in "B/sub" when they share the same 
> gitdir? It makes sense for "A/sub" and "B/sub" to share the same object 
> database, but they don't want to share the same HEAD.

True.  I am not a submodule user and do not have a strong interest
in submodules, but I agree that once the superproject wants to use
multiple worktrees, the submodules bound to it inevitably need to
use different worktrees that correspond to the worktrees used by the
superproject exactly because of the point you raise here.  They need
to be able to independently check out a suitable commit in the
context of the superproject's worktree that is checked out.