Every merge commit Gitea generates carries a malformed email address, and
it is in all four code repos.
$ git log origin/development origin/main --format='%ae' | sort -u
bit@das-labor.org <- correct, bit's own commits
no-reply+claude@chaosbit.de <- correct, my commits
bit@no-reply@chaosbit.de <- MALFORMED, generated by Gitea
claude@no-reply@chaosbit.de <- MALFORMED, generated by Gitea
Two @ signs. Not a valid RFC 5322 address, and not an address either of us
configured — our own commits are correct, which is what makes this easy to
miss.
Cause
Gitea composes the merge-commit identity as <username>@<NO_REPLY_ADDRESS>.
That setting is meant to be a domain, so it should read
[service]NO_REPLY_ADDRESS=no-reply.chaosbit.de
and it is evidently set to no-reply@chaosbit.de — an address. Gitea then
concatenates and produces claude@no-reply@chaosbit.de.
Why it is worth fixing even though it is cosmetic
It is in permanent history. main is protected against force-push, so
every existing merge commit stays wrong; this can only be fixed going
forward.
Anything that parses committer addresses — mailmaps, contributor stats,
changelog tooling, git shortlog -e — sees a broken address for the majority
of commits, since most commits on main arrive via merge.
docs/WORKFLOW.md is emphatic about commit identity and checks it before
every push. That check looks at the branch commit, which is correct, and
cannot see the merge commit Gitea creates afterwards — so our own guard was
never going to catch this.
Only bit can fix it
It is server configuration, not repository configuration; the token cannot
reach it. One line in app.ini plus a restart.
No action needed from me beyond this issue — nothing is broken, and I will not
try to work around it in commit messages.
Type/Bug, Priority/Low — permanent, but harmless to operation.
Every **merge commit** Gitea generates carries a malformed email address, and
it is in all four code repos.
```
$ git log origin/development origin/main --format='%ae' | sort -u
bit@das-labor.org <- correct, bit's own commits
no-reply+claude@chaosbit.de <- correct, my commits
bit@no-reply@chaosbit.de <- MALFORMED, generated by Gitea
claude@no-reply@chaosbit.de <- MALFORMED, generated by Gitea
```
Two `@` signs. Not a valid RFC 5322 address, and not an address either of us
configured — our own commits are correct, which is what makes this easy to
miss.
## Cause
Gitea composes the merge-commit identity as `<username>@<NO_REPLY_ADDRESS>`.
That setting is meant to be a **domain**, so it should read
```ini
[service]
NO_REPLY_ADDRESS = no-reply.chaosbit.de
```
and it is evidently set to `no-reply@chaosbit.de` — an address. Gitea then
concatenates and produces `claude@no-reply@chaosbit.de`.
## Why it is worth fixing even though it is cosmetic
- It is in **permanent history**. `main` is protected against force-push, so
every existing merge commit stays wrong; this can only be fixed going
forward.
- Anything that parses committer addresses — mailmaps, contributor stats,
changelog tooling, `git shortlog -e` — sees a broken address for the majority
of commits, since most commits on `main` arrive via merge.
- `docs/WORKFLOW.md` is emphatic about commit identity and checks it before
every push. That check looks at the *branch* commit, which is correct, and
cannot see the merge commit Gitea creates afterwards — so our own guard was
never going to catch this.
## Only bit can fix it
It is server configuration, not repository configuration; the token cannot
reach it. One line in `app.ini` plus a restart.
No action needed from me beyond this issue — nothing is broken, and I will not
try to work around it in commit messages.
`Type/Bug`, `Priority/Low` — permanent, but harmless to operation.
Independent confirmation of the cause, noticed while requesting a review on weblib-ci#10 and cheap to record: the malformation is not only in generated merge commits. The API reports it as the account's own address —
POST repos/weblib/weblib-ci/pulls/10/requested_reviewers
-> {"user": {"login": "bit", "email": "bit@no-reply@chaosbit.de", ...}}
So <username>@<NO_REPLY_ADDRESS> is being composed at the account level and merge commits are just where it becomes permanent. That corroborates the diagnosis above from a second angle without having to read any commits, and it means the one-line NO_REPLY_ADDRESS fix corrects both surfaces at once.
It also means anything that consumes the API's email field — not just git log — sees an invalid address today.
Independent confirmation of the cause, noticed while requesting a review on weblib-ci#10 and cheap to record: the malformation is **not only in generated merge commits**. The API reports it as the account's own address —
```
POST repos/weblib/weblib-ci/pulls/10/requested_reviewers
-> {"user": {"login": "bit", "email": "bit@no-reply@chaosbit.de", ...}}
```
So `<username>@<NO_REPLY_ADDRESS>` is being composed at the account level and merge commits are just where it becomes permanent. That corroborates the diagnosis above from a second angle without having to read any commits, and it means the one-line `NO_REPLY_ADDRESS` fix corrects both surfaces at once.
It also means anything that consumes the API's `email` field — not just `git log` — sees an invalid address today.
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.
Every merge commit Gitea generates carries a malformed email address, and
it is in all four code repos.
Two
@signs. Not a valid RFC 5322 address, and not an address either of usconfigured — our own commits are correct, which is what makes this easy to
miss.
Cause
Gitea composes the merge-commit identity as
<username>@<NO_REPLY_ADDRESS>.That setting is meant to be a domain, so it should read
and it is evidently set to
no-reply@chaosbit.de— an address. Gitea thenconcatenates and produces
claude@no-reply@chaosbit.de.Why it is worth fixing even though it is cosmetic
mainis protected against force-push, soevery existing merge commit stays wrong; this can only be fixed going
forward.
changelog tooling,
git shortlog -e— sees a broken address for the majorityof commits, since most commits on
mainarrive via merge.docs/WORKFLOW.mdis emphatic about commit identity and checks it beforeevery push. That check looks at the branch commit, which is correct, and
cannot see the merge commit Gitea creates afterwards — so our own guard was
never going to catch this.
Only bit can fix it
It is server configuration, not repository configuration; the token cannot
reach it. One line in
app.iniplus a restart.No action needed from me beyond this issue — nothing is broken, and I will not
try to work around it in commit messages.
Type/Bug,Priority/Low— permanent, but harmless to operation.Independent confirmation of the cause, noticed while requesting a review on weblib-ci#10 and cheap to record: the malformation is not only in generated merge commits. The API reports it as the account's own address —
So
<username>@<NO_REPLY_ADDRESS>is being composed at the account level and merge commits are just where it becomes permanent. That corroborates the diagnosis above from a second angle without having to read any commits, and it means the one-lineNO_REPLY_ADDRESSfix corrects both surfaces at once.It also means anything that consumes the API's
emailfield — not justgit log— sees an invalid address today.