Git development
 help / color / mirror / Atom feed
From: Phillip Wood <phillip.wood123@gmail.com>
To: Junio C Hamano <gitster@pobox.com>,
	Jimmy Aguilar Mena <kratsbinovish@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 0/3] worktree: add --recurse-submodules support to git worktree add
Date: Thu, 16 Apr 2026 19:38:12 +0100	[thread overview]
Message-ID: <19b86e02-6842-42f0-8226-c86ad6669ec4@gmail.com> (raw)
In-Reply-To: <xmqqzf3225u1.fsf@gitster.g>

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.

Thanks

Phillip


  reply	other threads:[~2026-04-16 18:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-16 16:32 [PATCH 0/3] worktree: add --recurse-submodules support to git worktree add Jimmy Aguilar Mena
2026-04-16 17:05 ` Junio C Hamano
2026-04-16 18:38   ` Phillip Wood [this message]
2026-04-17  9:38     ` Phillip Wood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19b86e02-6842-42f0-8226-c86ad6669ec4@gmail.com \
    --to=phillip.wood123@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=kratsbinovish@gmail.com \
    --cc=phillip.wood@dunelm.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox