amend that fixes a malformed trailer is refused as a duplicate Record-Id

[MongLong0214]

The commit-msg hook correctly warns that a wrapped Limit: line is not a trailer, then refuses the git commit --amend that fixes it. The only way out is --no-verify.

Sequence

Commit with a trailer block where two Limit: values are wrapped across two lines each, so they sit in their own paragraph above the real trailer block:

Limit: Fixtures intentionally copy the live authority tree; replacing that
structure with a wholly synthetic fixture is outside D0-013 exact ownership.
Limit: cleanupFixture intentionally suppresses cleanup errors so teardown
cannot obscure the test result; the known teardown-race tradeoff remains.

Warn: render witnesses depend on the live catalog and authority-tree fixture shape
Blast: local
...
Record-Id: r-d0013executionviewshardening

The hook lets the commit through with an accurate warning:

shape ok · references ok
commitlore: line 15 looks like a Limit trailer, but git did not parse it;
            the trailer block needs a blank line before it
commitlore: line 17 looks like a Limit trailer, but git did not parse it;
            the trailer block needs a blank line before it

git log --format='%(trailers:only=true,keyonly=true)' -1 confirms it: Warn Blast Undo Certainty Record-Id Follows Provenance X-Ticket. The two Limit values are absent from the record.

Amend the message to put both Limit: values on single lines inside the final block, keeping the same Record-Id:

$ git commit --amend -F fixed-message.txt
shape ok · references failed
21: duplicate-id Record-Id — got "r-d0013executionviewshardening",
    want "exactly one record per Record-Id"
commitlore: 1 violation (SPEC §6) — the message was not modified

Why this is wrong

--amend replaces the commit. After it, the old commit is unreachable from the branch and there is exactly one commit carrying that Record-Id. The duplicate the check reports does not exist in the resulting history — it exists only because the pre-amend commit was already recorded and the check does not know it is about to be replaced.

The two rules combine into a trap. The first rule tells you the message is malformed. The second rule blocks the correction, unless you either change the Record-Id — which is semantically wrong, since it is the same record — or bypass the hook. I used --no-verify, which is the outcome the hook exists to prevent.

Reproduction

• macOS, commitlore --version → 0.8.2
• Repository policy: {"mode": "auto", "unattended": true, "max_records_per_commit": 1, "require_verified_evidence": true}
• Commit a message with a wrapped Limit: paragraph above the trailer block; observe the warning and that the trailer is absent from %(trailers)
• git commit --amend with the same Record-Id and corrected formatting; observe duplicate-id
• git commit --amend --no-verify succeeds and %(trailers:key=Limit) then returns both values

What would resolve it

The uniqueness check needs to exclude the commit being amended. GIT_COMMIT is not set for commit-msg on amend, but git rev-parse HEAD during an amend is the commit being replaced, so the check can compare against it and skip a match. Alternatively the check could scan only commits reachable after the operation rather than the recorded set.

A narrower fix that would also help: refuse the original commit instead of warning. If a malformed trailer is worth a warning, and correcting it is blocked, the warning has no action attached to it.

What I could not determine

Whether the same trap applies to rebase -i reword and to commit --amend on a commit whose record was staged through the capture pipeline rather than written by hand. I only exercised the hand-written trailer path.

[MongLong0214]

Reproduction narrowed — it is not every amend

Measured, not inferred. Two amends against a repository with the hook installed:

Adding a Record-Id that was not there → accepted.
Three commits landed this way today (894f7af, 5a20638, feaf59a), each reporting shape ok.

Amending a commit that already carries a Record-Id, keeping the same id → refused.

$ git commit --amend -F <message with the same Record-Id>
commitlore: 1 violation (SPEC §6) — the message was not modified

So the trap needs the id to already be attached to the commit being replaced. The replaced HEAD is still counted as a live declaration of that id, and the amend that would replace it collides with it.

Why the narrower statement matters

The original text implied any amend that touches a trailer block is at risk, which made --no-verify sound like a general workaround for fixing malformed trailers. It is not: the ordinary repair — a commit whose trailers were wrong or missing an id — goes through cleanly.

The case that is actually blocked is the one where a record already exists and the author is correcting it: reword the Limit:, fix a typo in Ruled-out:, tighten a Verified: line. That is the normal editing loop for a record, and it is the loop that is closed.

Acceptance, restated

• amending a commit whose Record-Id is unchanged must be accepted; the replaced HEAD is not a second holder of that id
• the same id on any other reachable commit must still be refused
• adding an id to a commit that lacked one keeps working
• rebase reword, cherry-pick and squash checked for the same assumption

One caveat on today's evidence

The hook reported references not checked — the index is incomplete on at least one of those commits, so a fully built index might behave differently on the accepted path. The refusal above was reproduced on a fresh repository with a complete index, so the refusal is not an artifact of that; whether the acceptances would survive a complete index is not established here.

[MongLong0214]

Narrowed by experiment — the condition is one clause, not "amend"

The original report made every --amend and by extension every history rewrite look unsafe. It is not. The trap has one trigger:

git commit --amend that keeps the same Record-Id while changing the trailer payload.

Everything else passes without --no-verify.

Measured, in a scratch repository with hooks installed and a healthy index

index health — 8 trailers over 2 commits, current with HEAD — FTS5

case	payload	result
amend, reword subject only, same Record-Id	unchanged	shape ok · references ok
same, with another branch still holding the pre-amend commit	unchanged	shape ok · references ok
same, with a refs/notes/commitlore note carrying that id	unchanged	shape ok · references ok
amend, same Record-Id, one Limit: line added	changed	refused
same, on a commit with no note at all	changed	refused

shape ok · references failed
7: duplicate-id Record-Id — got "r-e638nonote", want "exactly one record per Record-Id"
commitlore: 1 violation (SPEC §6) — the message was not modified

A note on the commit is not required — the last row isolates that.

Why, from the source

src/core/stale.ts:515 and :536:

// Identical payloads are one record re-declared (§3.2) …
const signatures = new Set(declared.map(payloadSignature));
const identical = signatures.size === 1 && !signatures.has('');

Re-declaring an id with a byte-identical payload is forgiven by design. Two declarations with different payloads are a genuine collision by this rule — and an amend that corrects a trailer necessarily changes the payload. So the rule fires precisely on the repair.

This explains the three paths that were reported as passing

Rebasing commits that already carry Record-Ids, amending to add an id that did not exist, and reset --mixed followed by fresh commits all pass — and now for a stated reason rather than by luck. None of them re-declares an existing id with a different payload. An incomplete index was suspected as the cause of those passes; it was not. The repository above had a complete, current index and still passed on identical payloads and failed on changed ones.

What stays true, and is worse than first described

The trap is not merely present — it is aimed at the correction. The hook warns that a wrapped Limit: line was not parsed as a trailer, and then refuses the single edit that fixes it, because fixing it is what changes the payload. Changing the Record-Id to get past it would be semantically false: it is the same record.

Suggested acceptance

• an amend that keeps a Record-Id and changes its payload is accepted when the pre-amend commit is the one being replaced
• a genuine collision — the same id with different payloads on two commits that both remain in history — is still refused
• a regression covering both, so the fix cannot be "stop checking"

[MongLong0214]

Design note before anyone starts, because the obvious fix does not exist.

The narrowed condition, restated

Measured earlier in this issue: the refusal fires on git commit --amend that keeps a Record-Id while changing the trailer payload. Rewording only the subject passes, a note on the commit is irrelevant, and another ref holding the pre-amend commit is irrelevant. src/core/stale.ts:515 forgives a byte-identical re-declaration and treats differing payloads as a collision — and correcting a malformed trailer is exactly what changes the payload.

Why "skip the commit being replaced" is harder than it reads

The rule would be right to ignore a declaration that will not remain in history. During an amend, HEAD is precisely that. But the check runs in commit-msg, before the commit exists, and git gives a hook no signal that it is amending:

• no environment variable distinguishes commit --amend from commit
• the message file is COMMIT_EDITMSG either way
• comparing the incoming message to HEAD's fails as soon as the author edits it, which is the whole case here
• .git/rebase-merge and friends cover rebase and merge, not amend

So "exclude HEAD when amending" needs a fact the hook cannot observe. Any fix has to pick a different rule, and the choice is a product decision rather than an implementation detail:

1. Never count HEAD for duplicate-id, amend or not. Simple and observable. Costs the one case where somebody genuinely re-declares an id on the commit right after its original — which the payload-identity rule already forgives when the payloads match, so the loss is narrow.
2. Count HEAD only when the payloads differ and the new message is not a strict superset of the old one. Closer to intent, but it is a heuristic about editing, and heuristics here decide whether a record directs an agent.
3. Let the hook see the amend by having CommitLore's own prepare-commit-msg record the fact for the commit-msg that follows. It is the only option that observes rather than infers, and it adds coupling between two hooks that are currently independent.

My reading is that (1) is the honest one: it gives up something the existing payload rule already gives up, and it does not ask a hook to guess what the user typed. But it is a narrowing of a protocol rule, so it belongs to whoever owns SPEC §6 rather than to whoever picks up the ticket.

What is not the fix

Telling authors to use --no-verify. That is the outcome the hook exists to prevent, and it is what this issue was filed about.