[hieu-lee]

Problem

The "Setting up worktree…" phase of a new thread (fetch, then git worktree add) does git work that does not need to be serial or repeated:

• thread launch resolved the worktree base remote twice, so every launch paid for git remote and git for-each-ref (and a driver lookup) two extra times;
• createWorktree read checkout.workers and resolved the base ref one after the other, then ran the base-ref step after the checkout;
• the single-branch base fetch let git advertise and auto-follow every tag (791 on this repo) to fetch one branch.

Real traces from a dev server show each git spawn costing 40-340 ms under load, so the serial chain adds up before and after the checkout.

Solution

• fetchWorktreeBaseCommit accepts the remote the caller already resolved, and ThreadLaunchService passes it, so the remote is resolved once per launch.
• createWorktree reads checkout.workers and resolves the base ref concurrently before git worktree add. The base-ref config writes stay after the add and sequential, so they cannot race submodule init for config.lock.
• The scoped base fetch passes --no-tags, matching the other scoped fetches.

Measured on a 28k-file repo, checkout itself is 9-13 s and is untouched here. The fetch timing difference from --no-tags was inside noise locally (about 0.3 s); the saving grows with tag count. This PR cuts spawns and tag traffic, not file writes.

Tests: two new driver tests (no tags downloaded; a caller-resolved remote is honored), both verified to fail without the change, plus a ThreadLaunchService test that the fetch receives the resolved remote. Ran GitVcsDriverCore, GitManager, WorktreeMcpService and ThreadLaunchService tests (328 passed), server typecheck, lint and format.

Related, not fixed here: #21328 (new worktrees stay racily clean), #9853 (submodule objects re-cloned), #11930 (fetch waits on a GUI SSH agent), #26996 (shared pnpm store across worktrees).

Claude Sonnet 5.5 in Claude Code (T3 Code).

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at e76ffc0

Macroscope's review found this PR approvable — Worktree creation reuses remote resolution and overlaps independent reads, while branch-scoped fetches avoid incidental tag downloads. The changes retain existing branch-fetch safeguards and do not introduce destructive operations or change product defaults.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: b50d8a1
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: bd97085e-92b0-45e2-8eb2-e9fecdf16cde

Commits

Reviewing files that changed from the base of the PR and between e76ffc0 and 5df18b6.

Files selected for processing: 6

• apps/server/src/git/GitWorkflowService.ts
• apps/server/src/orchestration-v2/ThreadLaunchService.test.ts
• apps/server/src/orchestration-v2/ThreadLaunchService.ts
• apps/server/src/vcs/GitVcsDriver.ts
• apps/server/src/vcs/GitVcsDriverCore.test.ts
• apps/server/src/vcs/GitVcsDriverCore.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 8 remain after this review.

Walkthrough

Worktree launch now passes its resolved remote to base fetching. The Git driver accepts that remote, updates worktree base configuration, and uses explicit branch-specific fetch arguments that include --no-tags.

Changes: Worktree base remote handling

Layer / File(s)	Summary
Remote contract and launch propagation apps/server/src/vcs/GitVcsDriver.ts, apps/server/src/git/GitWorkflowService.ts, apps/server/src/orchestration-v2/ThreadLaunchService.ts, apps/server/src/orchestration-v2/ThreadLaunchService.test.ts	The fetch APIs use a named remote type. Worktree launch passes its resolved remote to base fetching. A test checks the project root, requested base ref, and resolved remote.
Git driver base handling apps/server/src/vcs/GitVcsDriverCore.ts, apps/server/src/vcs/GitVcsDriverCore.test.ts	The driver resolves the base before checkout and uses it for worktree configuration. Base fetching uses a supplied remote when present. Tests cover fetching a branch without downloading its tag and fetching with caller-supplied remote details.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Refactor

Possibly related issues

• pingdotgg/t3code#16183 — The changes update the same worktree base-remote resolution and fetch path, but do not change the hard-coded main default or missing-ref fallback identified in the issue.

Suggested reviewers: stbenjam, gigioxx

Merge Risk: Minimal · up to 5df18

No confirmed merge-blocking issue remains. Error handling during base resolution remains unverified.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly identifies the main change: reducing Git process spawns during server worktree creation.
Description check		The description is mostly complete. It explains the problem, solution, scope, measured impact, verification results, related issues, and agent usage. The “Solution” section serves the required change …
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Description check

Explanation

The description is mostly complete. It explains the problem, solution, scope, measured impact, verification results, related issues, and agent usage. The “Solution” section serves the required change section, and the verification details are specific.

Finishing Touches

Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

[hieu-lee]

@maria-rcks could you review this when you have a moment? CI is green on 5df18b6, Macroscope approved, and CodeRabbit had no actionable comments.

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

Verified unchanged head 5df18b68c3830581721eaf8dfb866cce303f61c9 on Linux. Installed dependencies and ran main (8760d063e9) and this head sequentially, with isolated app state and one dev server at a time. Used repository Playwright with /usr/bin/google-chrome. Added the real Git project through the UI, selected Codex gpt-6.1-sol, chose New worktree / From main (remote), and submitted a real provider turn through the local proxy. No mocks, seeded database, or replay provider.

• Main reproduced the redundant remote resolution: two git remote / upstream for-each-ref pairs before fetch. It also downloaded the remote-only verification-release tag.
• This head performed one pair, used fetch --quiet --no-tags -- origin +refs/heads/main:refs/remotes/origin/main, and left the local tag list empty. Base-ref resolution occurred before checkout; both base config writes occurred afterward. checkout.workers=2 was preserved.
• Both provider turns completed inside their new worktrees at the expected commit 556c40f, with clean working trees and readable project files.
• Neighbor: switched Start from remote off. The new worktree used unpublished local commit ebdf669, issued no launch fetch, and completed a real Codex turn.
• Neighbor: configured main to track upstream/main, advanced that remote independently, and launched with Start from remote on. It fetched upstream, checked out 8807e67 rather than local ebdf669, saved refs/remotes/upstream/main as the base, and Codex read the remote-only file. The original checkout stayed on its local commit.

Blacksmith verification passed: 377 focused tests; vp run check:changed b50d8a1b15eed3a75e1e0969765e14c6436d80d7 passed format, lint, knip, GraphQL generation checks, affected typechecks, and 332 tests. The worker needed PR history fetched before the comparison could run. GitHub CI is green. No source changes or pushes were needed.

Runtime command transcript

Not verified

Native iOS/Android clients, Electron-specific shell behavior, macOS/Windows, other providers, SSH authentication, submodules, and project setup scripts were not exercised on this Linux VM. This verifies fewer Git invocations and tag-fetch behavior; it makes no measured end-to-end latency improvement claim.