From 5a1a867faa6c99188086501ef893b88bac616fc8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?No=C3=A9=20Rubinstein?= Date: Mon, 9 Nov 2026 11:36:16 +0100 Subject: [PATCH] Document what goes wrong when a merged branch is deleted or pushed to Co-Authored-By: Claude Opus 5.5 --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index 137071f..e163417 100644 --- a/README.md +++ b/README.md @@ -137,6 +137,8 @@ jobs: * Works with squash merges and rebase merges: both land the branch's content as new commits without merging its history, so the children are re-parented onto the landed tip (the squash commit, or the last copied commit of a rebase merge). A PR merged with a merge commit keeps its history, so the action only retargets its children and deletes the branch. * If a merge hits a conflict, you'll need to resolve it manually; pushing the resolution automatically continues the stack update * Very large stacks might hit GitHub rate limits +* Don't delete a merged branch yourself; the action deletes it once the child PRs are updated. If you delete it before the action runs, GitHub moves the child PRs onto the trunk without updating them, so their diffs show the parent's changes, and the run may fail. +* Don't push to a branch after its PR is merged. If a child PR is waiting on a conflict resolution, the new commits end up recorded as merged in the child without their changes, and the action deletes the branch once the child is resolved. * After retargeting, GitHub sometimes keeps rendering a PR's diff against its old, deleted base, so the PR appears to contain already-merged changes. The branch itself is correct (`git diff ...HEAD` shows the real diff). Pushing any commit to the PR usually makes GitHub recompute. Sometimes it doesn't. Tough luck. ---