Guard stacked PRs from silent closure when deleting merged base branches

[Copilot]

Merging a stacked PR with branch deletion can silently close other open PRs that target the deleted branch as base. This updates the branch-sync guidance to prevent that failure mode and documents the correct recovery order when it already happened.

• Pre-delete safety check for stacked branches

  • Added an explicit precondition in feature-branch-sync.instructions.md: before deleting a merged branch, check for open PRs targeting it as base.
  • Added the operational rule: if dependents exist, do not use --delete-branch; retarget or restack first.

• Recovery path for accidentally closed stacked PRs

  • Added guidance that recovery requires restoring the deleted base branch first, then reopening the closed PR.
  • Clarified that reopening alone leaves the PR mis-based and does not restore restacking preconditions.

• Changelog update

  • Added an Infrastructure / Support entry in documentation/changelog.rst describing the new branch-deletion safeguard.

# Pre-delete check before merging with branch cleanup
gh pr list --base <branch> --state open

• Fixes Merging a stacked PR with --delete-branch silently closes the PRs that targeted the deleted branch #2632

[read-the-docs-community]

Documentation build overview

📚 flexmeasures | 🛠️ Build #34884757 | 📁 Comparing 7c70b97 against latest (d0903d0)

  🔍 Preview build  

1 file changed

± api/v3_0.html

[Flix6x]

Wouldn't a Claude hook be appropriate, too?

Please also read #2632 (comment) for finetuning documentation

[Copilot]

Wouldn't a Claude hook be appropriate, too?

Please also read #2632 (comment) for finetuning documentation

Implemented in 0d35764 and 69d927f.

• Added a Claude PreToolUse hook that blocks gh pr merge ... --delete-branch (.claude/hooks/merge-delete-branch-guard.sh) and registered it in .claude/settings.json.
• Refined .github/instructions/feature-branch-sync.instructions.md using the race-based explanation from your linked issue comment: merge first, verify gh pr list --base <branch> --state open is empty, then delete (or let auto-delete run).

[Flix6x]

Reviewed. Both of your requests are met: the Claude hook is here, and the instructions now carry the refined mechanism from #2632's follow-up — that merging retargets dependents and --delete-branch races that retarget, rather than deletion closing them outright. The recovery order (restore the base, then reopen) is right, and so is the note that reopening alone leaves the PR based on a branch that is still gone.

One hole, found and fixed in b8a7295

The guard matched only the long spelling. -d is the documented short form of --delete-branch on gh pr merge, and pflag bundles short booleans, so -sd and -ds say the same thing. Against the hook as it stood:

rc=2  gh pr merge 1234 --squash --delete-branch   BLOCKED
rc=0  gh pr merge 1234 --squash -d                allowed   <-- the command the guard exists to stop

I have pushed the fix rather than asking for it, since it is one line. The match now covers the long form, -d, and any bundled cluster containing d, and I checked it does not over-reach:

BLOCKED: --delete-branch, -d, -sd, -ds
allowed: plain merge, --admin, -t 'deadline fix'   (a value containing the letter, not a flag)
allowed: git branch -d x                           (not a gh pr merge at all)

One deliberate bluntness, which I would keep

The hook blocks --delete-branch unconditionally, rather than checking whether any PR actually depends on the branch. That is stricter than the rule it enforces. I would leave it: the alternative needs a gh pr list inside a 10-second hook, which means a network call that fails open exactly when the network is slow — and failing open is the whole problem. Being told to merge in two steps costs one extra command; the message says which two. Worth a line in the script saying that is a choice, not an oversight.

One question rather than a request

Does this belong in the changelog? It is an agent instruction plus a .claude hook — nothing a FlexMeasures user or operator can observe, where the entries around it in Infrastructure / Support are things like the /api/dev move. I would drop the entry and keep release notes about the product, but it is your call and I have left it in place.

Approving on the strength of the rest. Two things you have to do yourself, though: your Changes requested review still blocks the merge and only you can dismiss or supersede it, and the repository requires an approval that is not the author's — mine counts here since the author is the Copilot agent, but note I also pushed the fix above, so you may prefer to look at that one line before clearing your review.

[Flix6x]

Indeed remove the changelog entry.