[medium] perf(jj): detect repos without spawning and cache jj commands - #632

BLUF

• Priority: medium. This removes per-render subprocesses.
• Problem: each jj widget spawned jj root and then its own uncached jj command, with no timeout. With all 8 jj widgets configured, one render spawned 8 processes in a non-jj directory and 16 inside a jj repo.
• Fix:
  • A .jj directory walk decides "not a jj repo" without spawning anything.
  • jj commands now go through the same memory + persistent TTL cache as git and use the same 5 s timeout.
  • Read-only queries pass --ignore-working-copy.
• Result:
  • Spawns per render: non-jj 8 → 0; jj repo 16 → 6 (empty cache) or 0 (warm cache); right after a file edit, 16 → 7, then 2, then 0.
  • Render CPU: −22% in a non-jj directory, −45% in a jj repo with a warm cache.
  • Output is byte-identical to main.

Details

• Repo detection (isInsideJjRepo). jj finds its workspace by walking up to the nearest .jj directory, so the widget now does the same walk first. If there is no .jj, it returns false without spawning. If there is one, it still confirms with jj root. That keeps today's no jj output when .jj exists but jj is not installed.
• Caching. runGitArgs is split into a shared runCachedCommand in git.ts. This is a pure move: the git exec options, memory keys, persistent file layout and git.test.ts are all unchanged.
  • runJjArgs uses the shared cache and stores its entries in ~/.cache/ccstatusline/jj-cache/. Using a separate directory means colocated .git + .jj repos cannot collide.
  • Entries are invalidated by the mtimes of .jj/repo/op_heads/heads and .jj/working_copy/checkout. Every jj operation, including a working-copy snapshot, changes both, as checked with jj 0.45.1. Secondary workspaces follow the .jj/repo pointer file.
  • Commands that may snapshot (jj diff) take an optional refreshMetadata hook, so they are keyed to the repo state after they ran. Without it, the snapshot recorded by jj diff would invalidate the entry it had just written. Read-only commands stay keyed to the state before they ran, so an operation that lands concurrently still causes a refresh. The git path does not use the hook.
  • The TTL comes from the existing gitCacheTtlSeconds setting, default 5 s.
  • Like git's unstaged diff --shortstat, a file edit shows up in jj diff --stat within one TTL. jj also inherits the setting's existing "0 = mtime only" meaning: with a TTL of 0, an edit shows up only after the next jj operation. This is the same trade-off git widgets already have for unstaged changes with a TTL of 0.
• --ignore-working-copy. This is added to the change-id, description, bookmarks (heads(::@ & bookmarks())) and workspace-name queries. None of their output depends on file edits that have not been snapshotted: I checked each query with and without the flag after editing files, including with a bookmark on @, and the outputs matched. jj diff --stat still snapshots, because the snapshot is the data it reports. One side effect: in a stale workspace, these four queries may now show the repo view instead of failing to no jj. I did not reproduce a stale workspace to confirm this.
• Tests.
  • New unit tests cover: the timeout, the no-.jj path with zero spawns, discovery from a subdirectory, memory and persistent cache hits, cached failures, TTL expiry, invalidation on op-head and checkout changes, the secondary-workspace pointer, separate cache entries for allowEmpty, and post-run versus pre-run keying.
  • The new tests fail on main (red before) and pass with the change (green after).
  • The widget tests now run against a temporary .jj workspace with an isolated HOME, through a shared jj-test-helpers.ts.

Measurements

The setup: 8 jj widgets, jj 0.45.1, node dist/ccstatusline.js, and an isolated HOME for each arm. CPU is user+sys including reaped children. I ran 25 interleaved round-robin passes. Load1 during the run was min 50.8, median 61.2, max 68.6 on 6 cores, so compare ratios rather than absolute times.

Spawns per render. The first three rows were counted with strace -f execve. The post-edit rows were counted with a logging jj wrapper and a 60 s TTL, because strace under this load makes a single render take longer than the 5 s TTL.

The stdout of the patched build is byte-identical to main for the jj configs, in a jj repo and a non-jj directory, on cold and warm caches. It is also identical for the existing git3, default and heavy configs.

Checks

• bun run lint (tsc + eslint --max-warnings=0): clean.
• bun run build: OK.
• bun test:
  • All jj and git suites pass: 153 tests across jj.test.ts, git.test.ts and the 9 Jj* widget files.
  • The full run had 2302 passes and 66 failures, all in suites that do not touch jj or git: 36 in fetchUsageData error handling (5 s timeouts), 15 in custom-command capture, and 15 in TUI menus and editors.
  • I ran those same files on unmodified main (35440e4) under the same load. They failed there too: 52 failures in the usage-fetch and TUI files, and 16 in custom-command capture.
  • The host was running at load1 50–68 on 6 cores, so these are load flakes.
• Output is byte-identical to main. The patched build's re-keying change was re-checked after the benchmark run and still produced identical output.

This PR touches src/utils/git.ts (refactor only). As of opening, none of our other open PRs (including #624 usage-fetch.ts and #625 ansi.ts) touch git.ts or the jj files.

Overlap

• [medium] fix(git): stop respawning git outside repos and across session cwds #631 (also from me) edits src/utils/git.ts as well; the two branches conflict there. Whichever merges first, I will rebase the other.

🤖 Generated with Claude Code