Land the commit page and commit details reads as the first Git History branch

[Defmon3]

Seen on: component/git-history

What it fixes

The fork branch carries the whole Git History feature in one piece. The smallest useful server slice is: the contracts, a capability flag old clients can check, a read that returns a page of commits for a branch or for all branches, and a read that returns one commit's details. Nothing in it needs the UI.

Why we need it

It is PR 1 of the series in the Git History series issue (#8). It lands alone, is invisible to users, is testable against real git, and gives maintainers a small and safe yes. Every later piece builds on its contracts, so it has to be right first.

How to fix it

Cut a fresh branch from upstream main carrying the history contracts, the capability flag, the commit page read with its expiring cursor, the commit details read, their permission scope, and their tests. The signed-commit defect is fixed in this piece rather than carried. The PR description states the end state from the series issue. Deferred: branch and tag listing, changed files, diffs, and everything under the web app.

[Defmon3]

Technical appendix: Land the commit page and commit details reads as the first Git History branch

Investigated on branch component/git-history at commit 821fc7f, base upstream/main at a6797b3.

Findings: what the piece contains today

• packages/contracts/src/git.ts: GitCommitHash (40 or 64 hex characters), GitHistoryCommit, the history input and result with nextCursor and capped, and the commit details result. Test alongside.
• packages/contracts/src/rpc.ts: vcs.getHistory and vcs.getCommitDetails.
• packages/contracts/src/environment.ts and apps/server/src/environment/ServerEnvironment.ts: the capability flag a client checks before showing History; the web side reads it through hasGitHistoryCapability.
• apps/server/src/vcs/GitVcsDriverCore.ts: getHistory (about 90 lines), getCommitDetails (about 50), parseGitHistory and parseGitCommitDetails (about 80 together), the history snapshot map with storeHistorySnapshot, newHistoryCursor, deleteHistorySnapshot, and the limits GIT_HISTORY_DEFAULT_LIMIT (100), GIT_HISTORY_SNAPSHOT_MAX_COMMITS (1001), GIT_HISTORY_SNAPSHOT_MAX_SESSIONS (64), GIT_HISTORY_SNAPSHOT_TTL_MS (5 minutes), GIT_HISTORY_MAX_OUTPUT_BYTES (512 KB).
• apps/server/src/git/GitWorkflowService.ts: the non-repository fallback for the same reads.
• apps/server/src/ws.ts and apps/server/src/auth/RpcAuthorization.ts: handlers and the read scope for the two methods.

Size: about 470 source lines plus the matching tests.

Findings: behavior established by reading

• getHistory wraps a client-supplied revision with --end-of-options, so a ref name beginning with - cannot be read as an option.
• getHistory and getCommitDetails do not pass --no-show-signature; see the issue "Git History fails for users who show commit signatures".
• executeGit goes through execute, which applies the driver's metrics and span wrapper.

Findings: test state

• apps/server/src/vcs/GitVcsDriverCore.test.ts: 109 pass, 2 fail on this branch. Both failing tests are unchanged from upstream and fail identically at a6797b3 on this Windows machine (run 2026-09-04 in a clean worktree).

The problem

Observed: the commit reads exist only inside a branch that also carries the ref listing, the file and diff reads, and the UI.

Once done: a branch from upstream/main contains only the contracts, the capability flag, and the two commit reads with their tests; a client on an older server sees the capability flag absent; a user with signature display enabled gets the same result as one without.