feat: re-analyse a repository at its latest revision

[parthrohit22]

Closes #448. Independent of #450/#451 — branches off dev.

The gap

There was no way to bring an imported repository up to date. The only route to a second revision was retyping the GitHub URL, and if the branch had not moved:

Repository has already been imported.

A 409. A wall, where the truthful answer was "you are already current".

The capability already existed

Re-importing at a new commit has always allocated a new revision in the same lineage (#298/#299/#400) — the duplicate check is per-commit, not per-repository. GET /repositories/{id}/lineage already serves the history and RepositoryLineageHistory already renders it. What was missing was any way to ask. This is wiring, not engine work.

POST /repositories/{id}/reanalyse

outcome	meaning	status
already-current	the head still names the sealed revision; nothing cloned, nothing imported	200
revision-imported	a new revision added to the same lineage	200

remoteHead comes back either way, so the UI can say which commit it checked rather than asking the reader to trust that it checked. previousRepositoryId is returned on import — that's the "from" side of a two-revision diff (#219).

Three decisions worth naming

The head is resolved with ls-remote, not a clone. "Has this moved?" is usually answered "no", and answering it by downloading and parsing the whole repository to learn one SHA is a poor trade. New GitHubClient.read_remote_head_commit, one round trip, no disk.

A head this client cannot read is a failure, not "unchanged." Reporting a repository as current on the strength of a failed lookup is worse than saying the lookup failed — 502, with a test pinning it.

Comparison is against the lineage head, not the revision being viewed. Opening revision 1 of a three-revision lineage and asking to re-analyse must not report the branch as moved and import a fourth copy of something already sealed.

Frontend

The action lives in the History panel and appears only for a lineage — an upload has no upstream, so it gets no affordance rather than one that refuses. already-current renders as a neutral role="status" line naming the commit; a new revision re-reads the history in place and navigates to what it found.

Verification

Live, against pallets/click (real network, dev database):

outcome:          already-current
remote head:      6aabf099bfdd4c1e75fe8d0e0d4241372b988ab1
sealed revision:  6aabf099bfdd4c1e75fe8d0e0d4241372b988ab1

The moved path is covered by tests, not by a live run — no repository in the dev database had moved since import, and I could not fake one: RepositoryRecord enforces revision immutability (Repository revision identity is immutable once written), which is the right invariant and correctly refused the shortcut. What the moved branch does that the first import does not — pass the record's own url/branch, report previousRepositoryId, advance the lineage — is asserted directly; the import itself is the same _import_github_revision every GitHub import already runs.

7 new backend tests (unmoved, moved, older-member, upload, cross-owner 404, missing 404, unreadable head). 3 new frontend tests including "the panel re-reads its own history". Full backend suite green, ruff clean, test_openapi_contract.py updated, frontend contract regenerated, 460 frontend tests + tsc + eslint clean.

Unrelated, found while testing

github/demo-repository no longer resolves — git ls-remote returns "Repository not found". That's the repository the marketing hero's demo panel walks through.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
partha-frontend	Ready	Preview	Sep 11, 2026 5:40pm UTC