You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

31 lines
1.6 KiB

---
status: accepted
date: 2026-10-05
last-verified: 2026-10-05
owner: shared
source: maintainer decision of 2026-10-05
---
# Decision 15: Merge stacked pull requests in order with merge commits
- Choice: A stack of pull requests whose branches build on each other is
merged into `master` in order, each with **Create a merge commit**. The
merges wait for the CI run of the last pull request, which contains every
commit of the stack; an earlier one may fail tests that a later one fixes.
- Rationale: Squash and rebase merges rewrite the commits, so every later
pull request would conflict, and the commit IDs in the descriptions and
the changelog would no longer exist on `master`. A merge commit keeps
them, and each merge leaves `master` at the tree its pull request tested.
- Applied: 5.0.0-rc2, the PRs #99 to #106 on 2026-10-05; 5.0.0-rc7, the PRs
#116, #120, #118, and #119 on 2026-10-10.
- Operating rule (2026-10-10): retarget each pull request of the stack to
`master` (`gh pr edit <n> --base master`) before the one below it is merged,
and delete a head branch only when no open pull request uses it as its base.
Deleting a base branch through the GitHub CLI closed #117 without a merge:
GitHub did not retarget it. The open reports cli/cli#1168 and cli/cli#14223
show the same events (the first says that the button on the pull request
page retargets, the second quotes a maintainer who sees a platform issue) and
report that a closed pull request can't be retargeted or reopened while its
base is missing (not tried here). #120, a new pull request from the same
head, replaced #117. Nothing was lost; no content conflicted.