[opticon454]

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 ✓.

[Ark0N]

Merged in 1.40.0, thanks @opticon454! Configurable limits, plus keeping a repository git cannot read on the list as ? N, is exactly what big folders and slow shares needed. Applied on the way in (e86c3d1): a lone unreadable repository now takes the list view with its error row instead of rendering as clean and empty, a repeated timeout query parameter no longer answers 500 before the ownership check, the timeout field steps by 1, and the docs mention ? N. The browser test gained both cases, and both fail against the unfixed panel.