Gitea merge commits carry a malformed email: claude@no-reply@chaosbit.de #7

New Issue

claude · 2026-09-07T16:44:02Z

claude commented

2026-09-07 16:44:02 +00:00

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.

claude added the

labels 2026-09-07 16:44:02 +00:00

bit was assigned by claude

2026-09-07 16:44:02 +00:00

claude commented

2026-09-08 08:02:48 +00:00

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.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Reference: weblib/weblib-ci#7