docs: Harden stacked-PR recovery to resolve merge SHA from the PR#60
Merged
Conversation
thecodedrift
marked this pull request as ready for review
July 11, 2026 07:39
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the stacked-PR runbook in CLAUDE.md to make “recovery after base-branch deletion” resolve the correct restore SHA via GitHub PR metadata instead of relying on origin/main^2, which can drift after subsequent merges.
Changes:
- Replaces
git rev-parse origin/main^2with a flow that looks up the merge commit SHA viagh pr view ... --json mergeCommit. - Expands the runbook guidance to explain why
origin/main^2is unsafe oncemainmoves past the relevant merge commit.
The base-branch restore step used `git rev-parse origin/main^2`, which only yields the child's merge-commit second parent while that merge is still main's tip. Once any later PR merges (or the tip is a squash/rebase commit), origin/main^2 points at the wrong SHA and restores the wrong branch head. Resolve the merge commit from the closed PR itself via `gh pr view --json mergeCommit`, then take its second parent — correct regardless of what has landed on main since. Surfaced by Copilot on the taskless/public port of this runbook (public#9); fixing it upstream here so it flows to public and taskless/taskless. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The restore step resolved the merge commit from <n>, the same placeholder used for the child PR in steps 2-3. But the child is the PR that gets *closed* by the base-branch deletion — it is unmerged, so its mergeCommit is null and git rev-parse "$MERGE_SHA^2" would fail. The merge commit belongs to the parent PR (merged with --delete-branch); its second parent is the deleted base branch's pre-merge tip. Split the placeholders into <parent> (merged) and <child> (closed), and add a lead-in naming the two PRs so the step reads unambiguously. Caught by Copilot review on this PR. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
thecodedrift
force-pushed
the
jakob/harden-stack-recovery-doc
branch
from
July 11, 2026 08:01
1115a8d to
89c15d5
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Harden the "Recovery if a child PR gets closed by base-branch deletion" step in the stacked-PR runbook so it resolves the correct SHA regardless of what has landed on
mainsince.The restore command used
git rev-parse origin/main^2to recover the child's merge-commit second parent. That's only correct while the child's merge is stillmain's tip — once any later PR merges, or the tip is a squash/rebase commit,origin/main^2points at an unrelated merge's second parent and restores the wrong branch head. The step now resolves the merge commit from the closed PR itself (gh pr view <n> --json mergeCommit) and takes its second parent.Surfaced by Copilot on the marketing team's port of this same runbook (
taskless/public#9). Fixing it here since thisCLAUDE.mdis the upstream copy — it flows down topublicandtaskless/taskless. The two other Copilot findings on that PR (thegithub.paginateworkflow_runs/jobscomments) were false positives —paginatenormalizes namespaced list responses to flat arrays — and were replied to and resolved there.Docs-only; no release note (carries
skip-changeset).