decision: agent commits are landing under three different author identities, including yours #186
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Surfacing a question only you can answer. Not blocking anything; I am not
holding any PR on it.
Observation
The branch
feat/issue-181-e2e-harnesson PR#185 carries commits under three
different author identities:
sneak@sneak.berlinclawbot@eeqj.decai2025@acidhou.seThe cause is mechanical: the shared clone's
user.emailis configured as you,so any agent that commits without overriding it inherits your identity. Agents
that do set their own identity get
clawbot, and at least one run picked up athird address from the environment.
Why I am raising it rather than quietly normalizing it
Every commit in this repo's recent history is machine-authored.
git logandgit blameare how anyone - including future agents, including you in sixmonths - works out who to ask about a line. Right now they answer that question
wrongly: work neither written nor reviewed by you is attributed to you.
For most repos this is untidy. For a wallet that signs transactions, the
provenance of a line of code is a security-relevant property, and a signed or
attributed commit that misstates its origin is worse than one that is honestly
attributed to a bot. It also interacts badly with any future decision to sign
commits or require signed commits on protected
main.I did not want to normalize this silently, because "make the history say
something different about who wrote this" is not a call an agent should make on
its own initiative.
Options
clawbot@eeqj.de. Honest, uniform, andmakes
git logimmediately legible: your commits are yours, everything elseis the bot. Requires setting
user.name/user.emailexplicitly in the agentworkflow rather than inheriting from the clone. Existing history is left
alone.
so they land uniformly. Only touches unmerged branches - PRs
#169,
#171,
#175,
#178 and
#185 - so nothing already on
mainis rewritten. Costs a force-push on each branch.
and it gets harder to fix the longer it runs.
Recommendation
(a), and not (b). Fixing it going forward is cheap and unambiguous.
Rewriting five in-flight branches to correct attribution is a lot of
force-pushing - and force-pushing branches that already carry completed review
history is exactly the kind of churn that loses review context. The mixed
commits already in flight are a small, bounded, comprehensible mess; I would
rather leave them legible than rewrite them.
If you disagree and want (b), say so and I will do it as a single sweep before
any of the five merge, rather than piecemeal.
Also worth your explicit call
Should
mainrequire signed commits? If yes, that decision is much cheaper tomake now, while the number of in-flight branches is five, than after 1.0.0. I
have not assumed either way and this issue is not blocked on it.
Update that changes the decision: squash-merging through Gitea rewrites the landed commit's author and committer to
clawbot, whatever identity the branch commits carried. Verified on the commit that just landed onnext(d93eda3, from #192) and on the three before it — allclawbot, nonesneak.So under the current workflow (branch per issue, squash-merged into
nextthrough the tracker) the misattribution never reachesnextormain. It exists only on unmerged feature-branch commits, which the squash discards.That makes (b) unnecessary — there is no mixed history to rewrite once those branches land — and reduces (a) to belt-and-braces. I am setting
user.name/user.emailtoclawbotper clone in every worker dispatch regardless, since it costs nothing and keeps the branch commits honest before they are squashed.Still open and unchanged: whether
mainshould require signed commits. That one is worth your call before 1.0.0.Recurred twice today, on the head commits of #291 and #286 — both authored and committed as
sneak <sneak@sneak.berlin>while the rest of their branch series isclawbot <clawbot@noreply.example.org>. Same mechanical cause: identity inherited from the clone rather than set explicitly.Option (a) is now enforced operationally — every worker sets
user.name/user.emailtoclawbotbefore committing, and both of those commits are being corrected as part of rework already in flight. No history that has landed is touched.Still yours to call, and neither is blocking: whether to sweep (b) across unmerged branches, and whether
mainshould require signed commits.Owner ruling, 2026-08-17: commit identity should be
sneak. Option (c) — leave it. This supersedes the earlier note recording option (a) as enforced.Consequences, applied now:
sneak <sneak@sneak.berlin>are correct. Inheriting the clone's identity is the intended behaviour; agents must not overrideuser.name/user.email.needs-reworkon this and nothing else — #281, #282, #284 and #298. That finding is withdrawn on all four; no branch is being rewritten and no force-push is being taken.The signed-commits question in the issue body was not answered and is not assumed either way; it is not blocking 1.0.0.
Closing.