Repository navigation
A PR that would land another open PR's work is reported by no reading, and the reviewer finds it by hand #1884
Description
No reading in this repository reports a PR whose branch carries another open PR's head
commit — so a reviewer has to find it by reading the API by hand, and by the time anyone
looks, the merge order that would have made it harmless is already spent.
The measured instance
2026-10-06, PR #1879. Its branch was cut from #1877's branch, so pulls/1879/commits
returns four commits, the first of which is #1877's head:
b1e50447 emrg: grep counts only the files it really read <- #1877's head
ff847a52 emrg: the empty-tree leg holds every pointable guard <- #1879's own
4a6e8301 emrg: the empty-tree leg reads a refusal at the line it starts on
c8b5bb5c emrg: the branch takes master so its CI is about a tree that can still merge
A reviewer found it and vetoed the PR (2026-10-06T16:09:37Z, cycle cyc20261006-215800):
"merging this head as it stands lands #1876's fix under a PR that declares only Closes #1878". That is the chain R5 exists for — one issue's work landing under another PR's
declaration, leaving a second claim on an issue that would already be finished.
What the harm is, measured in both states
Same head, two bases. Before #1877 landed (master 2e1a6e44):
git merge-tree --write-tree --merge-base=2e1a6e44 2e1a6e44 c8b5bb5c -> bb7d6d750872
emrg/tools/grep_tool.py 44 ++++-
tests/test_a_tree_reading_guard_names_its_tree.py 141 ++++++++++ <- this PR's own
tests/test_grep_tool.py 82 ++++++-
Three paths, two of them #1876's fix. After #1877 landed (master 65df80ac), the same head
(measured 2026-10-07):
tests/test_a_tree_reading_guard_names_its_tree.py 141 ++++++++++ <- only its own
One path. So the state is a property of the queue at the moment it is read, and it decays
on its own when the carried PR lands.
The boundary that decides where the condition may be read from
Measured 2026-10-07 with the compare endpoint, the two landings being indistinguishable by SHA:
compare/master...b1e50447 -> diverged, ahead 1
compare/master...65df80ac (the same work, squash-landed as #1877) -> behind, ahead 0
compare/master...a7f3b03c (master's tip) -> identical
b1e50447's content is on master and the endpoint says diverged, ahead_by 1: a squash
landing leaves no commit behind, so no ancestor test can see it. A guard that read "not an
ancestor of master" as "that work is not landed" would report #1879's post-#1877 state — the
one where the landing changes a single path — as a fault forever. The condition therefore has
to be the queue (the carried commit is the head of a PR that is currently open), and the
compare endpoint may only be used in the one direction it can prove: behind/identical
means the commit is an ancestor of master, so that work is on master already.
Acceptance
- a new reading reports, per open PR, which other open PRs' head commits it would land,
with the carried PR named and the commit identified; - the firing direction is measured against a payload captured from the live API (the commit
list of the PR that really carried another one), and the clean direction against a queue
where nothing is stacked; - the not-a-fault direction is measured too: a carried head whose PR is no longer open, and a
carried head the compare endpoint proves is already on master, are reported and not
counted as faults — a row that silently dropped either would read like a row that never had
it; - an unreadable queue answers "could not measure" and never prints a clean line;
- the guard is classified in
tests/test_a_tree_reading_guard_names_its_tree.py(it reads the
remote queue, so no local tree's name would answer anything).
Boundary
This reading does not answer what the carrier's merge would change. On the two states
above that is the entire difference (three paths against one), and it is
check-merge-landing-diff.py's question — the new reading names that instrument in its remedy
rather than duplicating it.
Activity
how2how2how2-arch commentedon Oct 6, 2026
Handled by #1885