Skip to content

feat(git-status): configurable max repositories and git timeout; keep unreadable repos listed - #543

Open
opticon454 wants to merge 1 commit into
Ark0N:masterfrom
opticon454:feat/git-status-limits
Open

opticon454 wants to merge 1 commit into
Ark0N:masterfrom
opticon454:feat/git-status-limits

Conversation

@opticon454

Copy link
Copy Markdown
Contributor

What

The Git status window's two hard limits become per-device settings (App Settings → Header & Panels → Bottom bar):

  • Git status: max repositories — how many repositories to list when the session's folder holds several projects instead of being one (1 to 50, default 12, as before).
  • Git status: git timeout — seconds one git command may run (5 to 120, default 30; it was a fixed 10 s).

Why

Reported on a folder of 26 repositories on a network share: the window said "Showing the first 11 repositories found under this folder." Twelve are read; git status in Archive-Configs took 10.0 s on that share, which is exactly the fixed timeout, so it errored and was dropped without a word. Hence 11 under a limit of 12, with no hint that one was skipped or why (Media took 7.8 s, close behind). Nothing is wrong with the repositories; the share is slow.

Changes

  • GitRunner takes an optional { timeoutMs } third argument (existing fakes that ignore it keep working). runGit uses it (default 30 s instead of the old constant), and the status, rev-parse, discovery and diff paths pass it through.
  • GitOverviewOptions.maxRepos / timeoutMs, clamped by resolveOverviewLimits (clampInt treats an empty or non-numeric value as "not given", not 0). The 30 s discovery cache is now keyed by the limit, so a list cut at 12 cannot answer a request for 30.
  • GET /api/sessions/:id/git-status and /git-diff accept maxRepos and timeout (seconds) query parameters, clamped server-side, so an odd value can never cost more than the module's own ceiling. The overview reports repoLimit. The diff route takes them too, so a repository listed because the limit was raised can still be opened.
  • A repository whose git status fails is kept in the list with status.state: 'error' and the reason (previously dropped). The window shows ⚠ could not read: git timed out, the indicator shows ? N and amber instead of ✓, and the tooltip says "N repositories could not be read".
  • The truncation line names the limit and the fix: "Showing the first 12 of more than 12 repositories under this folder. Raise “Git status: max repositories” in Settings → Bottom bar to see more."
  • Docs (api-reference, Settings Reference, Working With Files) and a changeset.

Tests

  • test/git-workspace-status.test.ts (+5): clampInt, resolveOverviewLimits defaults and both ends of the clamp, the limit and repoLimit with the cache not reused across limits, an unreadable repo kept with its reason, and the timeout reaching every git command.
  • test/routes/git-status-routes.test.ts (+1): the query parameters, clamped, with junk and empty values falling back to the defaults.
  • test/git-status.browser.test.ts (+1): the settings reach the request, clamp on save and never reach the strict PUT /api/settings; an unreadable repository and the truncation line render, and the indicator reads ? 1, not ✓.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JrzFKEdBLwVfu6ev2ZscJS

… unreadable repos listed

Settings (per device): Git status: max repositories (1-50, default 12) and git timeout (5-120 s, default 30, was a fixed 10). Both go to /git-status and /git-diff as maxRepos / timeout query parameters, clamped server-side (an empty value means the default). A repository whose git status fails stays in the list with the reason instead of being dropped silently, shows as '? N' in the indicator, and the truncation line now names the limit and the setting. The discovery cache is keyed by the limit.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JrzFKEdBLwVfu6ev2ZscJS
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant