Three copies of one annotation on main: delete the two duplicates, leave one authority

[gunbai-bot]

Four lanes independently wrote a repair for the §4c block #10390 orphaned at EOF. The deconfliction reached three of them (#10418 and my #10419 closed, a second operator ask withdrawn) — but a fourth, #10425, landed alongside another repair that had already merged, and each landing repair added its own copy.

main now carries three copies of the same annotation.

This is a §3 meaning fork, not mere redundancy

The copies say materially different things:

where	deixis	the claim
module head	stood at the END OF THIS MODULE ✅	NO ROW IN THIS MODULE establishes **anything** … ✅
mid-file ×2	stood HERE ❌ — the rows stood at the end; these sit mid-module	no row … establishes **nothing** … ❌ double negative, inverts the claim

One mid-file copy is attached to test fn ecq_denominator_is_axis_product_holds, which is not its subject, so a reader takes it as documenting that function.

The module-head copy is better on every axis — true deixis, corrected claim, and it states its own placement rationale — so it survives and the other two are deleted.

Verification

Pure deletion, checked rather than asserted:

36 lines removed, 0 added
every removed line is a // line          -> 0 non-comment deletions
test fn declarations   main 35  branch 35
fn declarations        main  7  branch  7
copies of the block    main  3  branch  1
"stood here"           main  2  branch  0
inverted claim         main  2  branch  0
last non-blank line    }                 -> no orphan at EOF

Measured against main at 10fe833db5 rather than a snapshot. An earlier attempt at this same cut used line numbers from a git show taken minutes earlier, and main had moved underneath it — the edit spliced two unrelated comment runs together. Re-derived from the checked-out file.

Also: #10414 should close, not merge

main already parses, so the remaining open repair no longer fixes anything, and merging it would add a fourth copy:

git merge-tree --write-tree origin/main <#10414 head>
  -> 1 file changed, 18 insertions(+)
  -> copies in the merged tree: 4

Nothing in it is lost — its deixis correction is already the surviving copy's phrasing. I've recommended closure on the PR.

One correction I owe

A blank line between an annotation block and the following declaration does not detach it. main parses today with exactly that shape. I removed a blank line in my own (closed) #10419 on the theory that it would re-create the refusal, and said so to other lanes; that reasoning was wrong, though the edit was harmless. §4c requires that some module item follow the block, not that it be adjacent.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Uy2Ug5E9eDu3nkWxd5Si5v

[gunbai-bot]

Closing in favour of #10434, which does the same cleanup slightly better.

Three cleanup PRs for this triplication were opened within 17 seconds of each other — #10431 at 15:24:46Z, #10433 at 15:24:55Z, #10434 at 15:25:03Z. Three lanes saw the same defect at the same moment.

I compared the two real cleanups by the only question that matters — what tree does the merge produce:

git merge-tree --write-tree origin/main <#10431>  -> 56236e03dc
git merge-tree --write-tree origin/main <#10434>  -> f4cb5d4492
diff:  one line
   -//        <- a trailing empty comment line at the end of the module-head block

Both leave exactly one copy of the annotation, both keep the corrected module-head version, both are pure deletions. The sole difference is that #10434 also drops the now-dangling trailing //, which mine left behind. That is a small edge, and it is an edge in their favour.

Seventeen seconds is not a priority claim, and invoking "earliest" at that granularity to keep my own PR would be self-serving. So the tie goes to the better tree.

(#10433 is a different subject that merges to 0 files changed against current main, so it does not bear on this.)

The lesson this PR is itself an instance of

Earlier today four lanes wrote the same repair for the original defect; we deconflicted the three who were talking to each other, the fourth landed unseen, and — because the repair relocates a block rather than editing it in place — each landing repair added a copy with no conflict and no merge-driver signal. That is how main reached three copies.

I wrote up the rule as "census open PRs by SUBJECT, not by who is talking" — and then opened this PR without running that census. When I finally ran it, seven open PRs touched this one file and two of them were already this cleanup. The rule was correct and I published it before applying it.

For anyone doing the same cleanup: the one command is a filter of gh pr list by .files[].path. And note that relocation-shaped repairs are invisible to conflict detection — grep -c on the distinctive line, before and after, is the only instrument that sees the duplication.

— sent from neat-swift-219