Extend the process-wide git fork cap beyond status fetches #537

New issue

Closed

opened 2026-08-20 02:56:02 +02:00 by dries · 0 comments

dries commented

2026-08-20 02:56:02 +02:00

Owner

From the review of PR #526 (fix: cap git status forks process-wide). Scope question raised there; filing so it doesn't get lost.

PR #526 caps concurrent git status subprocess forks via a package-level semaphore in internal/git/info.go (fetchSlots, acquired in cache.lookup around fetchFromGit; cache hits bypass it; release is panic-safe after commit bfc9c964). The fork-pressure rationale — many sessions/projects polling at once starving the chat path — applies equally to the other git subprocess paths in internal/git that remain uncapped:

diffs (session changes / working tree sidebars, fullscreen diff browser)
worktree listing/ops
branch listing

Decide whether status-only was intentional (status is the high-frequency poller; the others are user-action-driven) or whether the cap should move down a layer — e.g. a shared semaphore in internal/gitexec so every fork goes through one gate, with the status cache keeping its bypass-on-hit behaviour. If extending: keep the panic-safe defer pattern and the -race regression tests from internal/git/info_test.go as the template.

From the review of PR #526 (fix: cap git status forks process-wide). Scope question raised there; filing so it doesn't get lost. PR #526 caps concurrent `git status` subprocess forks via a package-level semaphore in `internal/git/info.go` (`fetchSlots`, acquired in `cache.lookup` around `fetchFromGit`; cache hits bypass it; release is panic-safe after commit bfc9c964). The fork-pressure rationale — many sessions/projects polling at once starving the chat path — applies equally to the other git subprocess paths in `internal/git` that remain uncapped: - diffs (session changes / working tree sidebars, fullscreen diff browser) - worktree listing/ops - branch listing Decide whether status-only was intentional (status is the high-frequency poller; the others are user-action-driven) or whether the cap should move down a layer — e.g. a shared semaphore in `internal/gitexec` so every fork goes through one gate, with the status cache keeping its bypass-on-hit behaviour. If extending: keep the panic-safe defer pattern and the `-race` regression tests from `internal/git/info_test.go` as the template.