What happens
gh pr merge --squash and the GitHub squash button both build the default body
by concatenating every commit message on the branch. Each of this project's
commits carries the FOLLOWING_AGENTS_PROTOCOL paragraph and the three
trailers, so a branch with N commits lands one commit carrying all of them N
times.
scripts/check-commit-trailers.py requires each to appear exactly once, so
the landed commit fails its own gate.
Measured
Each commit checked individually against <sha>~1..<sha>:
| Commit |
Result |
ddff09093 (#827, 8 commits squashed) |
FAILED — marker, Following-Agents-Protocol and AI-Assisted each repeated |
5da1d7f2f (#782) |
FAILED — same shape |
c01e4be93 (#825) |
OK |
d741d4f48 (#820) |
OK |
The two that pass came from branches short enough to have one trailer block.
This is not specific to any one PR.
Why it is not repaired in place
The defect is in a commit message on main. Repairing it needs a rewrite, and
AGENTS.md forbids --force and --force-with-lease on main by anyone,
ever. A follow-up commit cannot fix an earlier commit's message. So the landed
instances stay as visible debt and the fix has to be preventive.
Candidate fixes
- Land with a hand-authored squash body carrying exactly one trailer block.
This is already the documented practice; it is not enforced, and the forge's
default body is the trap.
- Teach
check-commit-trailers.py to accept a squash commit whose repeated
blocks are identical, and to fail only when they disagree. This trades an
exact-once rule for a consistency rule and needs its own spec plus red-before
evidence.
- Have CI check the merge result of a PR rather than only its branch commits,
so the defect is caught before it lands rather than after.
Note on measuring this
git log order matters when checking a range by hand. c01e4be93..5da1d7f2f
reports OK because c01e4be93 is the newer commit, so the range is empty —
the gate examined nothing and said so in the same words it uses for success.
Check a single commit with <sha>~1..<sha> and confirm the commit count.
What happens
gh pr merge --squashand the GitHub squash button both build the default bodyby concatenating every commit message on the branch. Each of this project's
commits carries the
FOLLOWING_AGENTS_PROTOCOLparagraph and the threetrailers, so a branch with N commits lands one commit carrying all of them N
times.
scripts/check-commit-trailers.pyrequires each to appear exactly once, sothe landed commit fails its own gate.
Measured
Each commit checked individually against
<sha>~1..<sha>:ddff09093(#827, 8 commits squashed)Following-Agents-ProtocolandAI-Assistedeach repeated5da1d7f2f(#782)c01e4be93(#825)d741d4f48(#820)The two that pass came from branches short enough to have one trailer block.
This is not specific to any one PR.
Why it is not repaired in place
The defect is in a commit message on
main. Repairing it needs a rewrite, andAGENTS.mdforbids--forceand--force-with-leaseonmainby anyone,ever. A follow-up commit cannot fix an earlier commit's message. So the landed
instances stay as visible debt and the fix has to be preventive.
Candidate fixes
This is already the documented practice; it is not enforced, and the forge's
default body is the trap.
check-commit-trailers.pyto accept a squash commit whose repeatedblocks are identical, and to fail only when they disagree. This trades an
exact-once rule for a consistency rule and needs its own spec plus red-before
evidence.
so the defect is caught before it lands rather than after.
Note on measuring this
git logorder matters when checking a range by hand.c01e4be93..5da1d7f2freports OK because
c01e4be93is the newer commit, so the range is empty —the gate examined nothing and said so in the same words it uses for success.
Check a single commit with
<sha>~1..<sha>and confirm the commit count.