You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks for the great work on stacked pull requests! I'd like to report one small bug on the merge UI:
Summary
This is about the github.com merge UI, not the CLI.
When I squash-merge a PR that belongs to a stack from its PR page, and I clear the "extended description" textarea before confirming, the resuElting squash commit still contains the body of the original branch commit. The same steps on a non-stacked PR in the same repository produce a squash commit with an empty body, as expected.
Replacing the description with any non-empty text is honored. Only the "empty" case is affected. It looks like the stack merge path treats an empty description as "not provided" and falls back to the default generated message, whereas the regular PR merge path respects the empty value.
Similar Issues and Discussions
Related but different: #493 / #285 / #311 (no edit form when merging a whole stack) and #209 (other message differences in the stack squash path).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Thanks for the great work on stacked pull requests! I'd like to report one small bug on the merge UI:
Summary
This is about the github.com merge UI, not the CLI.
When I squash-merge a PR that belongs to a stack from its PR page, and I clear the "extended description" textarea before confirming, the resuElting squash commit still contains the body of the original branch commit. The same steps on a non-stacked PR in the same repository produce a squash commit with an empty body, as expected.
Replacing the description with any non-empty text is honored. Only the "empty" case is affected. It looks like the stack merge path treats an empty description as "not provided" and falls back to the default generated message, whereas the regular PR merge path respects the empty value.
Similar Issues and Discussions
Related but different: #493 / #285 / #311 (no edit form when merging a whole stack) and #209 (other message differences in the stack squash path).
All reactions