github / github/gh-stack

Stack trunk is not migrated when the trunk branch's PR is squash-merged and the branch deleted

Open
#225 3 comments 9 reactions 0 assignees View on GitHub
bug topic: cli - sync
Dominant language
Go
Stars
1.5k
Forks
70
Avg merge
1d 8h
Merged PRs (30d)
7

Description

## Scenario

A stack whose trunk is itself a feature branch with its own PR to `main` (a common "stack on top of an in-review PR" setup):

```
main
└── feat/base → PR #1 (base: main) ← stack trunk, created with --base feat/base
└── feat/layer-2 → PR #2 (base: feat/base)
└── feat/layer-3 → PR #3 (base: feat/layer-2)
```

PR #1 is then **squash-merged** into `main` on GitHub and `feat/base` is **deleted**. GitHub automatically retargets PR #2's base to `main`.

## Observed

The stack's local metadata keeps `trunk: { branch: "feat/base", head: }` forever:

- `gh stack view --json` still reports the deleted branch as trunk.
- `sync` cannot fast-forward the trunk (its remote ref no longer exists), and nothing offers to migrate the stack onto `main`.
- Because the trunk commits were squashed, the layers also need a `rebase --onto` to shed the now-duplicated trunk commits — the merged-PR recovery that works so nicely for *stack members* doesn't cover the *trunk*.

## Expected

When the trunk's remote branch is gone and a merged PR from that branch into `X` exists, `sync` (or a dedicated command) should offer to migrate the stack trunk to `X` and cascade-rebase, mirroring the existing squash-merge recovery for in-stack branches. Even just a `gh stack init --retrunk ` escape hatch would help — today `init --adopt` refuses branches that already have PRs, so there is no supported path.

## Workaround that worked

1. `git branch -f feat/base origin/main` (keep the local trunk name, point it at main)
2. `gh stack rebase` (cascades cleanly; git skips the squashed patches)
3. Hand-edit the `gh-stack` JSON state file in `.git/` to set `trunk: { branch: "main", head: }`

After step 3, `sync` works normally again. Editing an internal state file obviously isn't a supported interface, hence this issue.

Version: gh-stack v0.0.8, gh 2.x, repo uses squash-merge as the default merge method.

Contributor guide

Open the contributing guide

Research direction

Start by reproducing the squash-merge scenario with `sync`, then inspect how `sync`, `rebase`, and `init --adopt` handle merged PRs and the `.git/` gh-stack state file. Compare trunk handling with the existing in-stack branch recovery; done means a deleted trunk can be migrated to the merged PR's target and its layers cascade-rebased without manual state editing.

Written by the indexing model from the issue text.

Assessment

Tech stack
git, github, go
Domain
cli
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.