Re: [PATCH 0/3] worktree: add --recurse-submodules support to git worktree add

[Phillip Wood <phillip.wood123@gmail.com>]

On 16/04/2026 19:38, Phillip Wood wrote:
> On 16/04/2026 18:05, Junio C Hamano wrote:
>> Jimmy Aguilar Mena <kratsbinovish@gmail.com> writes:
>>
>>> The approach follows Phillip Wood's and Junio's feedback: each linked
>>> worktree gets its own per-worktree submodule gitdir under
>>> $GIT_COMMON_DIR/worktrees/<id>/modules/<name>/, so HEAD, refs, and
>>> the index are independent per worktree while pack files and loose
>>> objects are shared via hardlinks.  The gitdir isolation is the same
>>> model git worktree already uses for the superproject.
>>
>> I do not quite follow.  The point of git-native worktree support
>> (which improved a lot compared to its precursor, "git-new-workdir",
>> is that it can work well in a hardlink-challenged platforms.  You
>> shouldn't worry about "hardlinking" yourself at all.
>>
>> After the superproject successfully did "submodule init", you can
>> move the submodule's repository with "absorbgitdirs" to
>> $GIT_DIR/modules/<submodule>/ of the superproject.  The primary
>> motivation behind this feature was that you can switch to a commit
>> in the superproject that does *not* have the submodule bound to it
>> at all (and obviously you do not want to lose the submodule
>> repository only because you tentatively switch to such a commit and
>> have to re-download when you switch back), but I think it gives the
>> single instance of submodule repository that you can share across
>> worktrees of the submodule.  Because the single directory created
>> with "absorbgitdirs" looks like a bare repository, you should be
>> able to create two worktrees off of that, with their own HEAD etc.
> 
> I haven't thought much about it but that would mean that "git worktree 
> remove" ought to remove the submodule's worktree when the worktree 
> containing the submodule is removed. Worktrees avoid hardlinks by 
> creating a "commondir" file in the worktree's gitdir which contains the 
> relative path to "$GIT_COMMON_DIR". I think we could probably do the 
> same here and create "$GIT_COMMON_DIR/worktrees/<id>/modules/<name>/ 
> commondir" containing "../../../../modules/<name>" if we want to store 
> the submodule's gitdir under the worktree's gitdir. That way removing a 
> worktree's gitdir removes all the gitdirs of its submodules without any 
> extra effort. There are probably other tradeoffs between the two 
> approaches that I've not thought of.

I've realized that creating the submodule's gitdir under the worktree's 
gitdir means that "git gc" running in the submodule repository wont see 
the per-worktree refs and index file and will happily prune those 
objects. Junio's suggestion avoids that problem.

Thanks

Phillip