Six open PRs append a rule to docs/development/review-checklist.md. Each is clean against main. Any one of them merging breaks the other five. All 30 ordered pairs conflict — measured, not predicted.
PR adds rule vs main
1209 18 clean
1219 19 clean
1172 20 clean
1237 21 clean
1240 22 clean
1342 23 clean
Simulated each merge and re-tested the rest against the result (git commit-tree on the merged tree, then git merge-tree per candidate):
after 1209 lands -> 1219 1172 1237 1240 1342 ALL CONFLICT
after 1219 lands -> 1209 1172 1237 1240 1342 ALL CONFLICT
after 1172 lands -> 1209 1219 1237 1240 1342 ALL CONFLICT
after 1237 lands -> 1209 1219 1172 1240 1342 ALL CONFLICT
after 1240 lands -> 1209 1219 1172 1237 1342 ALL CONFLICT
after 1342 lands -> 1209 1219 1172 1237 1240 ALL CONFLICT
Cause is mundane: every rule is appended at the same insertion point (end of ## Review conduct), so all six edit the same trailing context.
The good news — it is textual, not semantic
I checked the numbering separately, because a conflict that also renumbers is a different problem. It doesn't:
main carries rules 1–17.- The six PRs claim 18, 19, 20, 21, 22, 23 — each exactly once, no duplicates, no gaps.
- PR1209 shows a
-17. / +17. pair in its diff, which looks like a second rule 17. It isn't — the added line is byte-identical to main's rule 17; it is a reflow, and 1209's actual contribution is rule 18.
So all six can land in any order and the final document is correctly numbered 1–23. Every conflict is "both added text here", resolvable mechanically without touching content.
Suggested handling
Merge them in any order and expect to resolve five trivial conflicts, or ask each author to rebase after the previous lands. Either is fine; the point of this issue is that mergeStateStatus will show all six as fine right up until the first one merges, so whoever presses first should know the other five need a rebase rather than assuming they broke something.
Note on my own instrument, since it nearly produced the opposite finding
My first pass reported zero conflicts across all pairs. That was wrong: I passed git merge-tree --write-tree output (a tree) back into git merge-tree as if it were a commit, and it failed silently rather than erroring. A positive control — re-testing a PR against a tree that already contained a conflicting change, which must conflict — returned 0 and exposed it. The numbers above are from the corrected instrument, where that control returns 1.
Recording it because "all clean" is the answer everyone wants and it would have been believed.
Related
I was about to add a seventh rule and stopped — it would have made this worse without adding information. Holding it until the queue drains.
The numbering half of this generalises to the ADR collision in #1402: same repo, same failure that a per-PR check cannot see. There, the numbers do collide (a second ADR-025); here they don't. Worth having one guard cover both — "does this PR's new identifier already exist on the base, and does the file it appends to have other open PRs appending to it."
Six open PRs append a rule to
docs/development/review-checklist.md. Each is clean againstmain. Any one of them merging breaks the other five. All 30 ordered pairs conflict — measured, not predicted.Simulated each merge and re-tested the rest against the result (
git commit-treeon the merged tree, thengit merge-treeper candidate):Cause is mundane: every rule is appended at the same insertion point (end of
## Review conduct), so all six edit the same trailing context.The good news — it is textual, not semantic
I checked the numbering separately, because a conflict that also renumbers is a different problem. It doesn't:
maincarries rules 1–17.-17./+17.pair in its diff, which looks like a second rule 17. It isn't — the added line is byte-identical to main's rule 17; it is a reflow, and 1209's actual contribution is rule 18.So all six can land in any order and the final document is correctly numbered 1–23. Every conflict is "both added text here", resolvable mechanically without touching content.
Suggested handling
Merge them in any order and expect to resolve five trivial conflicts, or ask each author to rebase after the previous lands. Either is fine; the point of this issue is that
mergeStateStatuswill show all six as fine right up until the first one merges, so whoever presses first should know the other five need a rebase rather than assuming they broke something.Note on my own instrument, since it nearly produced the opposite finding
My first pass reported zero conflicts across all pairs. That was wrong: I passed
git merge-tree --write-treeoutput (a tree) back intogit merge-treeas if it were a commit, and it failed silently rather than erroring. A positive control — re-testing a PR against a tree that already contained a conflicting change, which must conflict — returned 0 and exposed it. The numbers above are from the corrected instrument, where that control returns 1.Recording it because "all clean" is the answer everyone wants and it would have been believed.
Related
I was about to add a seventh rule and stopped — it would have made this worse without adding information. Holding it until the queue drains.
The numbering half of this generalises to the ADR collision in #1402: same repo, same failure that a per-PR check cannot see. There, the numbers do collide (a second ADR-025); here they don't. Worth having one guard cover both — "does this PR's new identifier already exist on the base, and does the file it appends to have other open PRs appending to it."