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-harness on PR #185 carries commits under three
different author identities:
sneak@sneak.berlin
clawbot@eeqj.de
cai2025@acidhou.se
The cause is mechanical: the shared clone's user.email is 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 a
third 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 log and git blame are how anyone - including future agents, including you in six
months - 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
(a) All agent commits author as clawbot@eeqj.de. Honest, uniform, and
makes git log immediately legible: your commits are yours, everything else
is the bot. Requires setting user.name/user.email explicitly in the agent
workflow rather than inheriting from the clone. Existing history is left
alone.
(b) As (a), plus rewrite the existing mixed commits on unmerged branches
so they land uniformly. Only touches unmerged branches - PRs #169, #171, #175, #178 and #185 - so nothing already on main
is rewritten. Costs a force-push on each branch.
(c) Leave it. Zero effort. The history stays misleading about authorship,
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 main require signed commits? If yes, that decision is much cheaper to
make 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.
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-harness` on PR
https://git.eeqj.de/sneak/AutistMask/pulls/185 carries commits under **three
different author identities**:
- `sneak@sneak.berlin`
- `clawbot@eeqj.de`
- `cai2025@acidhou.se`
The cause is mechanical: the shared clone's `user.email` is 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 a
third 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 log` and
`git blame` are how anyone - including future agents, including you in six
months - 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
- **(a) All agent commits author as `clawbot@eeqj.de`.** Honest, uniform, and
makes `git log` immediately legible: your commits are yours, everything else
is the bot. Requires setting `user.name`/`user.email` explicitly in the agent
workflow rather than inheriting from the clone. Existing history is left
alone.
- **(b) As (a), plus rewrite the existing mixed commits** on unmerged branches
so they land uniformly. Only touches unmerged branches - PRs
https://git.eeqj.de/sneak/AutistMask/pulls/169,
https://git.eeqj.de/sneak/AutistMask/pulls/171,
https://git.eeqj.de/sneak/AutistMask/pulls/175,
https://git.eeqj.de/sneak/AutistMask/pulls/178 and
https://git.eeqj.de/sneak/AutistMask/pulls/185 - so nothing already on `main`
is rewritten. Costs a force-push on each branch.
- **(c) Leave it.** Zero effort. The history stays misleading about authorship,
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 `main` require signed commits? If yes, that decision is much cheaper to
make 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.
sneak
was assigned by clawbot2026-08-09 18:31:19 +02:00
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 on next (d93eda3, from #192) and on the three before it — all clawbot, none sneak.
So under the current workflow (branch per issue, squash-merged into next through the tracker) the misattribution never reaches next or main. 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.email to clawbot per 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 main should require signed commits. That one is worth your call before 1.0.0.
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 on `next` (`d93eda3`, from https://git.eeqj.de/sneak/AutistMask/pulls/192) and on the three before it — all `clawbot`, none `sneak`.
So under the current workflow (branch per issue, squash-merged into `next` through the tracker) the misattribution never reaches `next` or `main`. 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.email` to `clawbot` per 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 `main` should 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 is clawbot <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.email to clawbot before 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 main should require signed commits.
Recurred twice today, on the head commits of https://git.eeqj.de/sneak/AutistMask/pulls/291 and https://git.eeqj.de/sneak/AutistMask/pulls/286 — both authored and committed as `sneak <sneak@sneak.berlin>` while the rest of their branch series is `clawbot <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.email` to `clawbot` before 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 `main` should 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:
Commits authored/committed as sneak <sneak@sneak.berlin> are correct. Inheriting the clone's identity is the intended behaviour; agents must not override user.name/user.email.
Author identity is not a review finding. Four PRs currently sit in needs-rework on 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.
No history is rewritten anywhere, in flight or landed.
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.
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:
- Commits authored/committed as `sneak <sneak@sneak.berlin>` are correct. Inheriting the clone's identity is the intended behaviour; agents must not override `user.name`/`user.email`.
- Author identity is **not** a review finding. Four PRs currently sit in `needs-rework` on this and nothing else — https://git.eeqj.de/sneak/AutistMask/pulls/281, https://git.eeqj.de/sneak/AutistMask/pulls/282, https://git.eeqj.de/sneak/AutistMask/pulls/284 and https://git.eeqj.de/sneak/AutistMask/pulls/298. That finding is withdrawn on all four; no branch is being rewritten and no force-push is being taken.
- No history is rewritten anywhere, in flight or landed.
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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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.