feature-request: TTL-cache git subprocess output to cut per-render git calls

[pstuart]

Context

Step 5e Competitive Analysis (autonomous scan 2026-05-18, 2nd pass since 2026-05-08) surfaced a fresh ecosystem move worth mirroring:

ccstatusline (sirmalloc/ccstatusline, v2.2.19 shipped 2026-05-17) added persistent git subprocess caching with TTL at ~/.cache/ccstatusline/git-cache/. This is the only material differentiator the competitive set picked up in the 10 days since first-pass; CCometixLine, ccusage, and cc-statusline shipped nothing in window.

What Barista does today

modules/git.sh already has one perf optimization (single git status --porcelain instead of 4 separate git status/diff/ls-files calls — credit there), but every render still spawns ~3 git subprocesses inside a git repo:

• git rev-parse --git-dir (line 39)
• git symbolic-ref --short HEAD (line 46) — falls back to git rev-parse --short HEAD (line 49) on detached HEAD
• git status --porcelain (line 74; sometimes re-run at line 131 for modified-count)

On a large monorepo or a repo with many untracked files this is the most-likely-to-be-complained-about latency source. The fix mirrors ccstatusline's pattern but stays in Bash.

Proposed Phase 1 (scoped)

• Cache key: <repo-toplevel-path> (from git rev-parse --show-toplevel).
• Cache location: ${XDG_CACHE_HOME:-$HOME/.cache}/barista/git/<sha1-of-toplevel>.
• Cached payload: branch name + porcelain summary (or counts) — text file, atomic write.
• TTL: configurable (suggest 2s default, env BARISTA_GIT_CACHE_TTL; 0 = disable).
• Invalidation signal: mtime of .git/HEAD and .git/index newer than cache file → bust. This is cheaper than running git itself and covers the common cases (checkout, add, commit).

Why not just leave it

• Closes the one fresh axis ccstatusline opened in the last 10 days.
• Doesn't touch the zero-dep / single-file-Bash story (Barista's biggest moat per the analysis).
• Pairs naturally with BARISTA_DEBUG perf timings already used elsewhere in the codebase.

Out of scope for Phase 1

• Caching ahead/behind upstream counts (those involve network and are off by default already).
• Pruning old cache entries (separate Phase 2 chore if needed).

Asking the author

Two binary unblocks:

1. TTL default — 2s or longer? (ccstatusline default is 3s; Bash respawn is cheap so I'd default lower.)
2. HEAD/index mtime invalidation acceptable, or do you want a more conservative scheme (e.g., only TTL-based, no mtime peek)?

Filed by autonomous scan; no work shipped yet — waiting for an answer on those two before opening a PR.

---

Sources from analysis:

• ccstatusline releases — v2.2.16-v2.2.19 burst 2026-05-08..2026-05-17
• Internal: modules/git.sh:39,46,74,131