yellowjacket

Code Issues 55 Pull Requests 6 Actions Packages Projects Releases 12 Wiki Activity

Compare commits

merge into: yonlu/yellowjacket:docs/closing-keyword

yonlu/yellowjacket:v0.7.0 yonlu/yellowjacket:v0.6.0 yonlu/yellowjacket:v0.5.0 yonlu/yellowjacket:v0.4.0 yonlu/yellowjacket:v0.3.1 yonlu/yellowjacket:v0.3.0 yonlu/yellowjacket:v0.2.3 yonlu/yellowjacket:v0.2.2 yonlu/yellowjacket:v0.2.1 yonlu/yellowjacket:v0.2.0 yonlu/yellowjacket:v0.1.0 yonlu/yellowjacket:v0.0.1 yonlu/yellowjacket:v0.0.0

pull from: yonlu/yellowjacket:docs/retire-stale-planning-docs

Branches Tags

1 Commits

docs/closing-keyword .. docs/retire-stale-planning-docs

Author	SHA1	Message	Date
yonlu	97f2eb85ee	docs: put the closing keyword where Gitea will actually read it CI / check (push) Skipped CI / e2e (push) Skipped 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 #98 Closes #100	2026-08-18 17:13:30 -04:00

Author

SHA1

Message

Date

yonlu

97f2eb85ee

docs: put the closing keyword where Gitea will actually read it

CI / check (push) Skipped

CI / e2e (push) Skipped

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 #98
Closes #100

2026-08-18 17:13:30 -04:00

Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL

Expand all files Collapse all files

Compare commits

Diff Content Not Available