[Discussion] Recommended way to handle many submodules in worktrunk worktrees? Considering nested git worktrees

Open
  • Is something wrong?
#2,920 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
20/100
Issue type
Documentation
Clarity
Needs clarification
Activity status
Quiet
Tech stack
git
Domain
cli, developer-experience

Research direction

Start by reading the linked issues #1194, #1196, #777, and #1069, then compare the described nested-worktree approach with the standard git submodule update --init flow. The issue names no files or tests and asks for guidance rather than a specific change, so there is no implementation target or completion criterion yet.

Written by the indexing model from the issue text.

Description

Context

We use worktrunk on a large Gradle-based project with 25 git submodules. ~9 are libraries we maintain (read access); ~14 are private to other teams and we substitute prebuilt artifacts via Gradle's dependencySubstitution. The standard flow — wt switch --create followed by git submodule update --init — takes several minutes per new worktree because each submodule is re-cloned from the remote.

Pattern we're considering

Instead of re-initializing, use nested git worktree add: for each permitted submodule, run git worktree add $WT/$sub <commit> from inside $BASE/$sub. This produces a second worktree of the submodule, rooted at the parent worktree's submodule path — same mechanism that makes parent-repo worktrees instant. No network, no object duplication.

Start commit defaults to the parent worktree's index entry for that submodule (git rev-parse HEAD:$sub), which keeps parent's git status clean.

Rough numbers from a one-off test

Standard submodule update --init Nested worktree
9-submodule init minutes (network-bound) ~2s
Extra disk for .git data several GB ~0 (gitfiles only)
Full Gradle build + install works works

Tradeoffs we've already spotted

  • wt remove needs --force because detaching the nested submodule worktrees first leaves parent's git status with D entries.
  • git submodule deinit / git submodule absorbgitdirs become dangerous in this workflow — they would manipulate the shared git dir that base and all worktrees rely on.

What we'd like input on

Before committing to this pattern, we'd appreciate hearing:

  1. Has anyone shipped nested-worktree-as-submodule in a real workflow? Any non-obvious failure modes (git upgrades, gc/prune on shared git dirs, IDE integrations)?
  2. Is there a reason the worktrunk team has steered away from documenting this? Closed issues #1194 / #1196 / #777 / #1069 all focus on standard git submodule semantics; we couldn't find any nested-worktree mention.
  3. What's the recommended way to handle many submodules in worktrunk worktrees today? If the standard update --init flow is considered acceptable despite the speed cost, we'd like to hear why — there may be safety properties we're under-valuing.

Mostly looking for guidance from anyone who's been here before. Happy to go with the standard approach if there's a strong reason to.

Dominant language
Rust
Stars
8.8k
Forks
315
Avg merge
1d 6h
Merged PRs (30d)
204

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from max-sixty/worktrunk

All issues in max-sixty/worktrunk

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.