97f2eb8 was pushed to #99's branch while that PR was being merged, so the merge was computed against the older SHA (1a221a4's parents are 2013939 and 0821deb) and this commit never reached main. Cherry-picked here onto a branch whose name matches the issue.
What it changes
CLAUDE.md said the Closes list was unreliable and to close by hand. It is unreliable for a specific reason, and the rule can say what works:
docs: <subject>
<body>
Closes #100
Gitea parses commit messages that reach main; it does not parse the PR body, which closes something only if the merge copies it into the merge commit message. Measured across three merges in this repo:
The footer costs nothing elsewhere: Conventional Commits allows one, scripts/commit-check.sh only regexes the subject, and semantic-release reads the type from the subject — so no release decision changes. The existing rule that the issue number stays out of the subject is untouched and was never about the body.
The verify-anyway step stays, because a squash or a hand-edited merge message still drops a footer.
The experiment is still pending
#99 did not test this — no closing keyword reached main in that merge at all, so its outcome tells us nothing about footers either way. This PR is the test. Its commit footer is Closes #100; if #100 closes on merge with nobody touching it, the rule is confirmed. If it does not, the honest answer is that Gitea will not do this for us and CLAUDE.md should say only "close by hand and verify" — I will make that edit rather than leave a rule that does not work.
Verified: cherry-pick is clean, commit-check passed via the commit-msg hook, no code changed.
`97f2eb8` was pushed to #99's branch while that PR was being merged, so the merge was computed against the older SHA (`1a221a4`'s parents are `2013939` and `0821deb`) and this commit never reached `main`. Cherry-picked here onto a branch whose name matches the issue.
## What it changes
CLAUDE.md said the `Closes` list was unreliable and to close by hand. It is unreliable for a *specific* reason, and the rule can say what works:
```
docs: <subject>
<body>
Closes #100
```
**Gitea parses commit messages that reach `main`; it does not parse the PR body**, which closes something only if the merge copies it into the merge commit message. Measured across three merges in this repo:
| Merge | What reached the commit message | Result |
|---|---|---|
| #83 `3c3197d` | `Closes #9, #13, #14, …` | closed **5 of 10** — a comma list is only partially matched |
| #93 `2013939` | `Reviewed-on:` only | closed **nothing**; #92 stayed open behind a correct PR body |
| #99 `1a221a4` | `Reviewed-on:` only; `31ada14` said `Refs #98` | closed **nothing**, as expected |
The footer costs nothing elsewhere: Conventional Commits allows one, `scripts/commit-check.sh` only regexes the subject, and semantic-release reads the type from the subject — so no release decision changes. The existing rule that the issue number stays out of the **subject** is untouched and was never about the body.
The verify-anyway step stays, because a squash or a hand-edited merge message still drops a footer.
## The experiment is still pending
#99 did not test this — no closing keyword reached `main` in that merge at all, so its outcome tells us nothing about footers either way. **This PR is the test.** Its commit footer is `Closes #100`; if #100 closes on merge with nobody touching it, the rule is confirmed. If it does not, the honest answer is that Gitea will not do this for us and CLAUDE.md should say only "close by hand and verify" — I will make that edit rather than leave a rule that does not work.
**Verified:** cherry-pick is clean, `commit-check` passed via the `commit-msg` hook, no code changed.
Closes #100
yonlu
self-assigned this 2026-08-18 21:16:00 +00:00
CLAUDE.md said the Closes list was unreliable and to close by hand. It
is unreliable for a specific reason, and the rule can say what works.
Gitea parses commit messages that reach main. It does not parse the PR
body, which closes something only if the merge happens to copy it into
the merge commit message. Both halves were measured here: #83's merge
commit carried "Closes #9, #13, #14, ..." and closed five of the ten,
because a comma list is only partially matched; #93's merge commit body
was a lone Reviewed-on: trailer, so #92 stayed open behind a perfectly
correct Closes line in the PR description.
So the keyword goes in the commit body as a footer, one issue per line.
That costs nothing elsewhere -- Conventional Commits allows a footer,
commit-check only regexes the subject, and semantic-release reads the
type from the subject, so no release decision changes. The existing
rule that the issue number stays out of the subject is untouched and
was never about the body.
The verification step stays, because a squash or a hand-edited merge
message still drops the footer.
This commit is the experiment: if #98 and #100 close when this branch
merges without anyone touching them, the mechanism is confirmed.
Closes#98Closes#100
yonlu
merged commit 75525b67e4 into main2026-08-18 21:30:35 +00:00
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.
97f2eb8was pushed to #99's branch while that PR was being merged, so the merge was computed against the older SHA (1a221a4's parents are2013939and0821deb) and this commit never reachedmain. Cherry-picked here onto a branch whose name matches the issue.What it changes
CLAUDE.md said the
Closeslist was unreliable and to close by hand. It is unreliable for a specific reason, and the rule can say what works:Gitea parses commit messages that reach
main; it does not parse the PR body, which closes something only if the merge copies it into the merge commit message. Measured across three merges in this repo:3c3197dCloses #9, #13, #14, …2013939Reviewed-on:only1a221a4Reviewed-on:only;31ada14saidRefs #98The footer costs nothing elsewhere: Conventional Commits allows one,
scripts/commit-check.shonly regexes the subject, and semantic-release reads the type from the subject — so no release decision changes. The existing rule that the issue number stays out of the subject is untouched and was never about the body.The verify-anyway step stays, because a squash or a hand-edited merge message still drops a footer.
The experiment is still pending
#99 did not test this — no closing keyword reached
mainin that merge at all, so its outcome tells us nothing about footers either way. This PR is the test. Its commit footer isCloses #100; if #100 closes on merge with nobody touching it, the rule is confirmed. If it does not, the honest answer is that Gitea will not do this for us and CLAUDE.md should say only "close by hand and verify" — I will make that edit rather than leave a rule that does not work.Verified: cherry-pick is clean,
commit-checkpassed via thecommit-msghook, no code changed.Closes #100