perf(server): reuse local submodule objects when creating worktrees#9854

fixing since i do a lot of work on a repo with a decent amount of submodule content, so everytime i start a new thread (I have it start a new worktree based on origin for new threads), and send my first message, it would take ~18 seconds to setup the worktree, this does some work to cut that down.

======= below this line is ai slop =========

What Changed

Fresh worktrees clone submodule history again even when the source checkout already has the objects. Initialize each destination submodule using its matching source checkout as a temporary Git --reference, then --dissociate so the destination owns its objects. Repeat for nested submodules. Missing objects still come from the configured remote, and unsuitable references fall back to an ordinary clone.

Git's submodule wrapper retains only the last --reference, so each clone now receives exactly one matching reference. Custom submodule active/update policies and clone concurrency settings retain the ordinary recursive command. If preparation still fails, retry the ordinary recursive update so Git can process remaining siblings before the existing best-effort warning.

The production diff is 98 changed lines in the shared server Git driver; the only other changed file is its focused test suite. No new settings, persistent cache, dependencies, or client/protocol changes.

Closes #9853.

Why

An observed first-message startup spent 0.522 s fetching origin, 0.296 s adding the worktree, and 17.417 s initializing submodules. This change targets the dominant submodule step while preserving automatic population and independent worktrees.

Worktree setup measurements

72.1% less time · 15.82 seconds saved on average

Actual createWorktree() calls, including submodule initialization. Linux/btrfs · Git 2.55 · approximately 1 GiB of packed submodule history. Two runs per version, interleaved, using fresh destinations and the same pinned commit. Excludes origin fetch and provider startup; caches were not flushed.

Edge-case measurements on the final commit

The matrix below compares the original driver (8faf031c) with the unchanged PR head (1001b4cc0). 120 measured calls: 12 scenarios, five calls per implementation per scenario. Destination state matched the original driver in every measured call.

Positive percentages mean less elapsed time; negative percentages mean more. These are synthetic local file:// transport fixtures on Linux/btrfs, separate from the approximately 1 GiB repository measurement above. Ordinary modules contain approximately 16 MiB of history each (four revisions of a 4 MiB random payload); the tiny modules contain a README only. Nested modules use spaces in their paths, and submodule names differ from their paths.

The slower cases have small absolute costs in these fixtures, even where the percentage increase is large. The command paths and packet traces explain the likely sources of overhead; the timings measure the whole driver call, not the milliseconds attributable to each subprocess:

• 12 tiny cached modules: +164.1 ms (240.4 → 404.5 ms). The optimized runs made zero object want requests, so reuse worked. Each module still requires a separate update invocation, reference setup, and dissociation to preserve independence. With only README-sized histories to transfer, this setup costs more than the transfer work it saves.
• Four shallow sources: +124.9 ms (308.3 → 433.2 ms). Git rejects shallow repositories as clone references, so the attempted reference clones retry as ordinary clones. The fixture shows no reduction in object requests; reference attempts and per-module setup add work. See Git's reference validation.
• Four uninitialized sources: +44.4 ms (327.1 → 371.5 ms). There are no initialized source checkouts to borrow from. The driver checks for references and invokes updates per module, but each module still needs ordinary cloning.
• An unreachable first module: +21.1 ms (326.5 → 347.7 ms). The per-module attempt fails before the driver retries the ordinary recursive command, which processes the healthy siblings. This fixture fails immediately at a local missing URL; a slow remote failure can make retries more costly.

Custom active/update/concurrency settings use Git's ordinary recursive path after the configuration checks. Their measured mean differences range from 12.2 ms less to 17.4 ms more; the fetchJobs=4 difference is 0.6 ms more, with substantial sample variation. Those small differences do not establish either an optimization or a precise overhead cost for custom policies.

For interactive first-message setup, the 44–164 ms penalties in the tiny/shallow/uninitialized fixtures are likely minor: they are paid once when creating a worktree, not on every subsequent message in that worktree. This is a practical assessment, not a measured perceptibility result. The separate large-repository sample saved 15.82 seconds; that is context for the tradeoff, not a promise that the same user receives both results. More modules or slower failures can increase the penalty, so the negative rows remain visible rather than being treated as universally negligible.

Regression coverage

• 65 tests pass in GitVcsDriverCore.test.ts on Node 24.20.0. The cached fixture uses two siblings and a nested submodule over file:// transport; packet tracing asserts no object want requests when the matching source repositories already contain all objects. This assertion fails on the original PR implementation (462f597) and passes with the correction.
• Fixtures cover stale/populated, shallow and uninitialized sources; spaces and differing submodule names; a caller in a project subdirectory; a selected commit missing from the source; and a remote newer than the selected commit.
• Staged, unstaged and untracked source changes remain untouched and are not copied into the destination. Destination submodules retain the selected gitlinks and pass fsck and reset --hard after source object stores are deleted.
• Active-submodule selection (including the literal submodule.active=true pathspec) and update=none keep their ordinary Git behavior. An unreachable first submodule still allows Git to clone healthy siblings. Both added edge-case tests fail on 57a6e533d, pass against the original baseline, and pass with the correction. The existing best-effort checkout-failure test remains passing.
• Targeted lint, formatting, server-only typecheck and git diff --check pass. Typecheck reports existing unrelated Effect suggestions, with no errors. No correctness regression was observed in this coverage. The edge-case measurements above record both speedups and timing regressions.

Checklist

• This PR is small and focused
• I explained what changed and why
• Focused behavioral tests and before/after measurements are included

Model and harness: GPT-6 / Codex.