fix(release): list squash-merged PRs in the generated changelog - #226
Merged
Conversation
release.sh derived its CHANGELOG section from `git log --merges` whenever any merge commit existed in the range, falling back to non-merge subjects only when there were none. That silently dropped every squash-merged PR as soon as ONE merge commit was present. This repo's history mixes both styles: #215/#216 landed as merge commits, #217-#221 as squashes. The v0.3.0..HEAD range therefore generated 2 bullets instead of 7 — omitting five shipped fixes and naming the v0.3.0 release PR itself as a change in the next release. Walk the base branch's first-parent chain instead. One bullet per landed change, whatever shape it landed in: - a merge-committed PR contributes its merge subject (rewritten to "#N: branch") - a squash-merged PR contributes its squash subject - a merged PR's internal commits stay excluded — they hang off the second parent, which is the double-listing the --merges-only path was really guarding against A direct-to-base commit is on the first-parent chain and is a real shipped change, so it is now listed too. Tests: scenario A's "non-merge commit is excluded once merge commits exist" assertion encoded the old behaviour and is inverted, paired with a new assertion that merged PRs' internal commits are still never double-listed. New scenario H covers mixed merge+squash history — the real v0.3.0..v0.3.1 shape — asserting exactly one bullet per landed change. release.test.sh: PASS (51 checks) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
robercano-ghbot
added
the
needs-human
Collaborator
Author
|
fix(release): list squash-merged PRs in the generated changelog (not yet reviewed) |
robercano-ghbot
added
claude-ci-fixing
robercano-ghbot
added
the
needs-human
Collaborator
Author
|
fix(release): list squash-merged PRs in the generated changelog (not yet reviewed) |
robercano-ghbot
added
needs-human
Collaborator
Author
|
fix(release): list squash-merged PRs in the generated changelog (not yet reviewed) |
robercano-ghbot
removed
the
needs-human
robercano
approved these changes
Aug 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Prerequisite for cutting v0.3.1: without this,
release.shwould generate a wrong changelog for that release.The bug
release.shderived its CHANGELOG section fromgit log --mergeswhenever any merge commit existed in the range, and fell back to non-merge subjects only when there were none. So a single merge commit in range silently discarded every squash-merged PR.This repo's history mixes both styles — #215/#216 landed as merge commits, #217–#221 as squashes. Simulating the generator over the real
v0.3.0..origin/mainrange:Two bullets instead of seven. It omitted all five shipped fixes (#217, #218, #219, #220, #221) and named the previous release's own PR as a change in the next one.
The fix
Walk the base branch's first-parent chain. One bullet per landed change, whatever shape it landed in:
#N: branch--merges-only path was really guarding against, and--first-parentgets it without discarding anything.Verified against real history: 7 first-parent entries in
v0.3.0..origin/main(5 squashes + 2 merges), with #216's two internal commits correctly dropped.Tests
release.test.shscenario A carried"in-range non-merge commit is excluded once merge commits exist", which encoded the old behaviour deliberately. That assertion is inverted, and paired with a new one asserting merged PRs' internal commits are still never double-listed.New scenario H covers mixed merge+squash history — the exact
v0.3.0..v0.3.1shape — asserting both styles appear and the section holds exactly one bullet per landed change.Gates
GATES_FILE=self/gates.json— build: pass, lint: pass.test:release.test.shpasses; the suite as a whole has one pre-existing, unrelated failure inpr-feedback.test.shscenario C that also reproduces on pristineorigin/mainand at thev0.3.0tag (see the review comment below).