#30 Show what a merged change request landed · vole

keenan opened this 13d ago

Why

The Files tab reviewed an open request with a three-dot diff against the base branch. Once the request lands, the head is in the base, so the merge base of the two is the head itself and the diff is empty by definition. A merged request therefore showed “Already merged into main” and no files — the review surface disappeared exactly when someone would look back at what the merge changed.

What changed

The landing mark records merged_base, the base tip the merge started from, in the same commit that records merged_head, merged_by and merged_at:

merged_base: 3f2a9c1...   # what the base pointed at before it moved
merged_head: 7b41e08...   # what landed (the head, or the merge commit)

vole change merge passes the tip it replaced, so the record names the “before” side of the change. A retry that finds the head already landed has no base tip of its own to name and passes nothing, which keeps whatever the record already says instead of replacing it with the moved tip.

The Files tab now diffs merged_base against the landing, so a merged request shows what it changed — the head for a fast-forward, the merge commit for a non-fast-forward, which includes conflict resolution. merged_base is optional on read because landings made before the field existed have none; those fall back to the merge commit’s first parent when the landing was a merge, and claim nothing when it was a fast-forward and the starting point is gone.

The request page shows the file count and the review link for a merged request too, with the merge named beside it, instead of replacing them with “Already merged”.

Checks

vole workflow check
vole workflow run verify (format, vet, build, govulncheck, packages, markdown links, go test -race ./...)
New coverage: a merged record’s merged_base is written by a fast-forward and by a merge-commit landing, survives a retry, and is validated when read; the diff range picks the recorded base, the merge parent fallback, or nothing for a legacy fast-forward; and an end-to-end landing keeps the changed file on the request page and the Files tab.

Discussion (2)

keenan 13d ago

Follow-up on this request: the Files tab’s tree now starts with every folder expanded, so a change that touches several directories shows all of its files at once instead of folding each one behind a click. Folders can still be collapsed by hand, and the browser’s tree sync keeps opening the ancestors of a file it navigates to.

Head moved to 43f98bcd; the previous approvals (none yet) no longer apply. The tree test now also asserts an unrelated nested folder is open, and the request files page test checks the rendered open attribute and a nested changed file. vole workflow run verify passes.

keenan 13d ago

The branch/head discussion here produced two follow-up issues:

#01M5XMWZ31K4607MHTXCD2VNZE — a contributor cannot move the head of their own open request: the only path is vole change update --head, which writes the metadata branch and needs maintain; the web and SSH have no equivalent.
#01M5XMWZ310Z7W7N43T997HAQ6 — the head branch is discarded when a request is opened, so the page shows only main ← 43f98bcd. Recording it as advisory metadata would be a display change; head: stays the reviewed commit.

Neither changes this request.