[ymichael]

What was wrong

Workspace watch startup spawned eight Git processes per workspace. Provisioning, local state, and shared refs independently checked the same repository; provisioning also read the Git directory separately, and shared refs queried origin/HEAD separately from its ref listing.

What changed

Startup now uses four Git processes for a workspace with a resolvable origin/HEAD:

1. One rev-parse --is-inside-work-tree --is-bare-repository --git-dir --git-common-dir supplies both provisioning checks. Local/shared reads reuse the known repository result.
2. The existing ignored-directory status scan runs before watcher setup.
3. The existing fresh local-state status scan runs after root watch readiness.
4. One for-each-ref listing supplies branch refs and origin/HEAD's target using %(symref).

When the listing omits refs/remotes/origin/HEAD, the existing git symbolic-ref refs/remotes/origin/HEAD call remains as a fallback. Those workspaces use five processes, including repositories with no origin/HEAD or a dangling/unresolvable target. The same rule handles files and reftable storage, without reading ref-storage internals.

Both status scans remain because their ordering closes the setup window. WatchManager and host-watcher match main: no setup snapshot is cached. Snapshot fingerprints keep their existing representation, including the symbolic default-branch target, so retargeting origin/HEAD to another branch at the same commit still invalidates metadata. There are no daemon wire, CLI, or configuration changes.

How you verified

pnpm exec turbo run typecheck lint test --filter=@bb/host-daemon --filter=@bb/host-workspace --filter=@bb/host-watcher --concurrency=2 passed 13/13 tasks (four-checks-final.log).

• Real-Git default-branch coverage runs against files and reftable storage: missing origin/HEAD, a resolvable target, a changed target at the same commit, dangling targets/chains, and local-branch fallback. Reftable cases skip only if Git cannot perform the migration. Both formats pass locally. Negative controls disabling either the unlisted-HEAD fallback or the listed symbolic target fail the assertions.
• Provisioning coverage includes ordinary checkouts, linked worktrees, bare repositories, plain directories, and repository paths containing spaces/newlines where supported.
• The setup-window regression still passes: after ignore discovery, it edits README and changes main→feature before root subscription activation, with no watch event delivered. It verifies content invalidation, dirty content status, and feature metadata. The same test failed on the former setup-cache implementation 1bfe2c22a0, reporting main. Before/after evidence remains in setup-window-before.log and setup-window-after.log.

Common-case startup measurements

Five fresh-process samples per version at 1, 5, and 20 workspaces, alternating main/branch and branch/main order. Baseline: origin/main c0013e2aba. Branch: a7c6c2c3f7. The source snapshots were captured at b859834f4e; the final head changes only test fixture initialization, and all measured production source files match it byte for byte (four-revisions.json). No older five/six-process samples are pooled into these results.

Used the existing external startup.mjs harness and startup-report.md method, with the same isolated clone and native-watched linked worktrees. The clock starts before replaceWatchSet, including provisioning, ignore discovery, and watcher setup. Watch-ready ends at the last workspace-root readiness callback; completion ends at the last Git child exit. The 1.6-second observation floor and 650-ms idle wait are excluded. Our package tests and fixture setup had finished before sampling; no browser, server, or status-request traffic was generated.

Workspaces	origin/main Git processes	Branch Git processes	Reduction
1	8	4	50%
5	40	20	50%
20	160	80	50%

Counts were identical across all five samples in each cell. All 30 samples produced exactly one initial content invalidation and one metadata message per workspace, identical branch/default-branch/path/worktree values, and no raw watch events.

All workspace-root watches ready, median (min–max), ms:

Workspaces	origin/main	Branch
1	96 (91–132)	88 (84–96)
5	227 (222–307)	215 (203–247)
20	1630 (1508–7808)	2028 (1342–6408)

Startup completion, median (min–max), ms:

Workspaces	origin/main	Branch
1	175 (171–227)	156 (152–181)
5	398 (393–477)	383 (375–425)
20	1821 (1650–8460)	2104 (1438–6908)

The process reduction is consistent; timing is mixed. Readiness medians improved slightly at 1/5 workspaces and regressed at 20. Both versions have wide 20-workspace ranges. These samples do not establish a general latency improvement.

The original measure.mjs harness with zero event repetitions independently confirms 8→4, 40→20, and 160→80 processes. Separate one-workspace missing-HEAD and dangling-HEAD runs each confirm 8→5, with identical metadata between main and the branch (four-fallback-summary.json); these count checks are excluded from the timing tables.

Scripts, source snapshots, JSON traces, fixtures, logs, and the report remain outside the checkout under /Users/michael/.bb/thread-storage/thr_ci4wag9p6h/branch-perf/dedup/. The harness adaptations change import paths to preserved snapshots; instrumentation and settle rules are unchanged. four-run-samples.py reproduces the primary series, four-summarize.py validates counts/report parity and computes the tables, and four-fallback.py checks fallback counts. Primary traces are startup-four-*-<count>-<0..4>.json.

CI on final head a7c6c2c3f7 is green: 18 successful checks, 8 skipped. The PR remains open and unmerged.

AGENT GENERATED