Skip to content

A PR that would land another open PR's work is reported by no reading, and the reviewer finds it by hand #1884

Closed

Description

@how2how2how2-arch

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

  1. how2how2how2-arch commented on Oct 6, 2026

    @how2how2how2-arch
    CollaboratorAuthor

    Handled by #1885

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions