Add a git-hygiene rule for signing identity during a history rewrite - #394
Conversation
A history rewrite that re-signs commits (e.g. filter-repo to strip PII) preserves each
commit's author but makes the runner the signer, so a blanket re-sign stamps the maintainer's
key over bot-authored commits (dependabot[bot], github-actions[bot]) - a signature that does
not match the author, which GitHub marks unknown_key/unverified and a require-signed-commits
ruleset rejects. This has recurred three times, and AGENTS.md only stated the principle in
passing ("you cannot sign another contributor's commits for them") without an operational rule.
Add an explicit two-gate rule to AGENTS.md "Git and Commit Rules": scope the rewrite to only
the commits that must change (by default your own, re-signed with your key), and if a commit
that must change is not yours, re-identify its author/committer to the signing identity before
re-signing so signature and author agree. Cross-reference it from the brownfield re-signing note
in docs/repo-config-carry.md.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>There was a problem hiding this comment.
Pull request overview
Adds an operational, explicit git-hygiene rule to prevent producing commits whose signing identity cannot be verified after a history rewrite (for example, when re-signing rewritten history that originally came from bots), and threads that guidance into the repo-config carry documentation.
Changes:
- Add a new “history rewrite” bullet under AGENTS.md -> Git and Commit Rules describing two gates for safe rewrites and a post-rewrite verification check.
- Extend docs/repo-config-carry.md brownfield migration guidance with a cross-reference to the new rule when bot commits are involved.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| AGENTS.md | Adds a new operational rule for scoping history rewrites and aligning rewritten commit identity with the signing key. |
| docs/repo-config-carry.md | Adds a cross-reference in the brownfield migration section pointing readers to the history-rewrite rule. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
…uthor GitHub verifies a commit signature against the committer identity, not the author, so the rule was inaccurate and internally inconsistent (it claimed the rewrite makes the runner the committer, then keyed on author-matching). Re-center it: a your-key signature over a commit still committed by a bot or GitHub web-flow is what GitHub marks unknown_key/unverified, so the second gate sets the committer (and author, since the content changed) to the signing identity. Fix the repo-config-carry cross-reference the same way, and replace the fragile author/signer log check with git log --show-signature. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (1)
AGENTS.md:33
- The verification guidance says to confirm commits are "signed and committed under your identity", but
git log --show-signatureshows the author by default and may not display the committer identity you are trying to validate. Also, "a your-key signature" is grammatically awkward.
Consider rephrasing that clause and using a git log format that includes the committer (e.g. --pretty=fuller) so the check actually validates committer vs signer.
- **A history rewrite includes only the commits that must change, and re-identifies any commit it rewrites that is not yours.** Filtering history (`git filter-repo` / `filter-branch`, e.g. to strip PII) rewrites the touched commits and you re-sign them with your key, while the tooling preserves each commit's original `author` and `committer` unless told otherwise. GitHub verifies a signature against the commit's `committer` identity, so a your-key signature over a commit still committed by a bot (`dependabot[bot]`, `github-actions[bot]`) or by GitHub's web-flow does not match its committer and is marked `unknown_key`/unverified, which a require-signed-commits ruleset then rejects. Two gates keep committer and signature aligned. **First, scope the rewrite to only the commits that must be modified** - by default those are your own, whose committer is already your identity, and a commit that does not need changing is kept out of the rewrite so its identity and signature are never touched. **Second, if a commit that must change is not yours, set its `committer` to the signing identity before re-signing** (and its `author` too, since a rewrite that alters the content should not keep attributing it to the bot), so the committer GitHub verifies matches your key - the original bot attribution is deliberately given up as the cost of having to rewrite it. Never leave your signature over a commit committed by another identity. Verify after the rewrite that every rewritten commit is signed and committed under your identity (`git log --show-signature`).
Uh oh!
There was an error while loading. Please reload this page.
A history rewrite that re-signs commits (e.g.
git filter-repoto strip PII) preserves each commit'sauthorbut makes the runner the signer, so a blanket re-sign leaves the maintainer's key over bot-authored commits (dependabot[bot],github-actions[bot]) - a signature that doesn't match the author, which GitHub marksunknown_key/unverified and a require-signed-commits ruleset rejects. This has now recurred three times (most recently ESPHome-Config PR #59), and AGENTS.md only stated the principle in passing ("you cannot sign another contributor's commits for them") without an operational rule.Change
author/committerto the signing identity before re-signing, so signature and author agree.Verification
CRLF preserved, no em-dash (fleet uses spaced hyphens), markdownlint clean.
🤖 Generated with Claude Code