From 98687856b45e166f5da31dc1ddb37f5820b06a13 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?No=C3=A9=20Rubinstein?= Date: Thu, 11 Jun 2026 13:47:54 +0200 Subject: [PATCH] Document GitHub's stale diff after retargeting Co-Authored-By: Claude Fable 5 --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 8607321..b544cd8 100644 --- a/README.md +++ b/README.md @@ -135,6 +135,7 @@ jobs: * Built for squash merges. A PR merged with a merge commit keeps its history, so the action only retargets its children and deletes the branch. Rebase merges are not supported: the action detects them through GitHub's commit-PR association (the merge method itself is recorded nowhere) and comments on each child PR instead of acting. * 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 +* 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. ---