Skip to content

feat: record base SHA at gw new --stack for a deletion-proof restack - #51

Merged
zawakin merged 1 commit into
mainfrom
feature/stack-base-sha
Jun 29, 2026
Merged

feat: record base SHA at gw new --stack for a deletion-proof restack#51
zawakin merged 1 commit into
mainfrom
feature/stack-base-sha

Conversation

@zawakin

@zawakin zawakin commented Jun 29, 2026

Copy link
Copy Markdown
Contributor

What

Step 4 (final) of the stacked-restack package. gw new --stack now records the base tip SHA in branch.<child>.gwBaseSha, and the pre-PR StackedBaseMerged hint uses it as the git rebase --onto boundary.

Why

The pre-PR restack hint used the base branch name as the --onto boundary. But a child that has no PR yet isn't protected by the cleanup guard (#49 only sees open child PRs), so the base branch can be deleted before the child opens its PR — leaving the name unresolvable.

The recorded SHA equals the fork point (since --stack branches off the current HEAD) and still resolves after the base branch is gone, so the suggested git rebase --onto origin/main <sha> keeps working.

Changes

  • git: branch_base_sha / set_branch_base_sha; unset_branch_base now clears both gwBase and gwBaseSha (used by gw sync on restack).
  • new: record gwBaseSha alongside gwBase under --stack.
  • next_action / status: thread recorded_base_sha through DetectContext into the StackedBaseMerged hint, which prefers the SHA over the branch name.

Test

  • next_action: test_recorded_base_merged_carries_recorded_sha.
  • tests/new_test.rs: --stack records gwBaseSha == the parent's HEAD.
  • mise run verify passes.

Note / known edge

The recorded SHA is the base tip at stack time. If the base later advances and the child re-stacks onto the newer tip, the SHA is a stale boundary; while the base branch still exists, gw sync uses origin/<base> (the live ref) which handles that correctly. The SHA is the fallback for the base-deleted, pre-PR case.

This completes the stacked-PR package (#48 hint, #49 cleanup guard, #50 sync --onto, this).

🤖 Generated with Claude Code

The pre-PR restack hint (StackedBaseMerged) used the base branch NAME as the
`git rebase --onto` boundary. But a child with no PR yet isn't protected by
the cleanup guard (#49 only sees open child PRs), so the base branch may be
deleted before the child opens its PR — leaving the name unresolvable.

gw new --stack now also records the base tip SHA (branch.<child>.gwBaseSha),
which equals the fork point since --stack branches off the current HEAD. The
StackedBaseMerged hint prefers that SHA as the `--onto` boundary, so it still
resolves after the base branch is gone. gw sync clears both keys on restack;
branch deletion clears the rest.

- git: branch_base_sha / set_branch_base_sha; unset_branch_base clears both keys
- new: record gwBaseSha alongside gwBase
- next_action/status: thread recorded_base_sha into StackedBaseMerged's hint

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@zawakin zawakin self-assigned this Jun 29, 2026
@zawakin
zawakin merged commit 0af78e3 into main Jun 29, 2026
6 checks passed
@zawakin
zawakin deleted the feature/stack-base-sha branch June 29, 2026 13:10
zawakin added a commit that referenced this pull request Jun 29, 2026
Reflect the stacked-PR work (#48-#51) in the skill's stacking section: gw sync
restacks with rebase --onto (replaying only the child's commits, not the merged
parent's), gw status guides the pre-PR case, and gw cleanup keeps a base branch
alive while an open child PR still targets it. Adds a note on why --onto is
required after a squash merge.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant