Correct the History-Rewrite Premise That filter-repo Re-Signs Commits - #4185

Summary

Corrects the history-rewrite premise in git-commit-conventions. The skill and its references/history-rewrite.md said git filter-repo re-signs every commit it touches. It does not. It strips every commit signature it processes and signs nothing, so a rewritten history lands unsigned. Per the maintainer's answer on #3750, this stays inside the existing skill and its reference rather than a new skill.

• references/history-rewrite.md states the facts the rules follow from: a rewrite cascades to every descendant, git filter-repo strips signatures and signs nothing, and GitHub verifies a signature against the committer. The gates now state the reach first, re-sign in a separate signing pass, re-identify only the committer, and keep the author. Verification reads GitHub's commits API (verification.verified and reason) rather than git log --show-signature. The signing-pass example sets the committer and moves tags with it. Gate 4 stops an agent before the force push, which stays the maintainer's. A collateral list covers tags, remote tags and pull request refs, other clones, and published artifacts.
• SKILL.md "History rewrites re-identify only what changed" carries the same corrected summary.
• docs/repo-config.md "Brownfield Migration" aligns its re-signing guidance with the same premise.
• Generated .github/skills/ and .claude-plugin/ copies regenerated with scripts/build_dist.py, and --check is clean.

Verification

• A constructed throwaway repository with a throwaway ed25519 SSH key and synthetic example.invalid identities, run under setsid --wait timeout. All of its commits, a merge included, read %G? = G. A git filter-repo --mailmap run changing one commit's author left every commit on every branch unsigned (N, zero gpgsig headers). That included the root commit it did not change, and every descendant's hash changed. A following git filter-branch --commit-filter 'GIT_COMMITTER_NAME=... GIT_COMMITTER_EMAIL=... git commit-tree -S "$@"' -- --branches pass re-signed every commit (G). It set the committer, kept each author (a bot author included), kept the merge's parents and both dates, and left every tree hash and the commit count unchanged. With --tag-name-filter cat -- --branches --tags, a lightweight tag and a signed tag both moved to re-signed commits on the branch, and the rewritten signed tag no longer verifies (git verify-tag).
• The procedure covers a default, whole-history git filter-repo run. A constructed range-limited run (--refs) left other branches and tags on the old commits, so the reference gives no range-limited variant.
• git filter-repo's own documentation states that a rewritten commit's signature is removed. GitHub's REST commits documentation lists the commit.verification fields and defines the no_user, unverified_email, and bad_email reasons by the committer email.
• The verification command's --jq projection was checked read-only against this repository's own develop.
• The brownfield re-sign in a plain clone rewrites only local branches, so docs/repo-config.md says to create a local branch for each remote one first and follows the reference's gates.
• Gate 1's git for-each-ref signed-tag listing, and git tag -f -s <tag> '<tag>^{commit}' producing a tag that verifies, checked in a constructed repository. The gate 4 command shape was checked read-only against this repository's develop.
• prose_lint.py --diff origin/develop, markdownlint, cspell, and editorconfig-checker (scripts/docker_lint.py) pass. GOVERNANCE.md "Git and Commit Rules" ("re-identifies only the commits it touches that aren't yours") stays true and is unchanged.

Open introduced findings (local pass edit budget spent)

• references/history-rewrite.md gate 4, introduced: the maintainer's force push could overwrite a commit pushed to the remote while the rewrite ran, since nothing records each remote tip for a --force-with-lease=<branch>:<sha> push. Outcome: declined. The reference prescribes no push command and hands the push to the maintainer, who composes it, and a lease procedure is a new rule History-Rewrite Guidance Assumes filter-repo Re-Signs What It Rewrites, So Both Gates and the Verification Step Miss the Real Failure #1391 does not ask for.
• docs/repo-config.md "Brownfield Migration", introduced: the migration sends the reader to the whole-history signing pass, which also re-signs commits older than the earliest unsigned one. Outcome: declined. git-commit-conventions "Signing must be live before the first commit" already states that this retrofit rewrites the entire history and makes the rewriter the committer and signer of every commit in it.

Closes on promotion: #1391

🤖 Generated with Claude Code