You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
modify fails after sync --prune: "unknown revision" for pruned merged branches
#564
gh stack modify fails to open after gh stack sync --prune has pruned merged branches. It aborts while resolving branch SHAs for branches that --prune itself deleted, instead of skipping them the way view and rebase do.
Steps to reproduce
Have a stack with one or more merged PRs still listed (e.g. main <- merged-a <- merged-b <- active-c <- active-d).
Run gh stack sync --prune. The merged branches' local refs are deleted, but their entries remain in the stack metadata (.git/gh-stack) — this is the documented behavior ("Stack metadata is preserved so that rebase and display logic continue to work correctly").
Run gh stack modify.
Actual
✗ failed to apply modifications: building snapshot: resolving branch SHAs: failed to run git: fatal: ambiguous argument 'merged-a': unknown revision or path not in the working tree.
modify resolves every branch entry (including pruned-merged ones) by name via git, and dies on the first one whose ref no longer exists.
Expected
modify should tolerate pruned merged branches — skip them the same way view and rebase already do (e.g. ✓ Skipping merged-a (PR #NNN merged)), and open the TUI over the remaining branches.
Notes
gh stack view and gh stack rebase work fine in this state; only modify chokes.
The two commands are internally inconsistent: sync --prune produces a stack state that modify cannot read.
Workaround: manually remove the merged branches' entries from .git/gh-stack.
I have a fix for this on my fork: modify-pruned-merged-branches. I couldn't open a PR because PR creation seems limited to collaborators.
BuildSnapshot (internal/modify/apply.go) resolves every branch by name, so it fails on the first merged branch that --prune deleted. The fix leaves merged branches with no local ref out of the snapshot. There's nothing to restore for them, and their metadata is still saved in StackMetadata, so rebase keeps its merged-commit cutoffs and recovery never recreates a pruned branch.
TestBuildSnapshot_SkipsPrunedMergedBranch reproduces the error above and fails without the change. go vet and the full scripts/test suite pass. I'm happy to open it as a PR if a maintainer can enable that, or anyone is welcome to pick up the commit.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Version:
gh stackv0.2.1Summary
gh stack modifyfails to open aftergh stack sync --prunehas pruned merged branches. It aborts while resolving branch SHAs for branches that--pruneitself deleted, instead of skipping them the wayviewandrebasedo.Steps to reproduce
main <- merged-a <- merged-b <- active-c <- active-d).gh stack sync --prune. The merged branches' local refs are deleted, but their entries remain in the stack metadata (.git/gh-stack) — this is the documented behavior ("Stack metadata is preserved so that rebase and display logic continue to work correctly").gh stack modify.Actual
modifyresolves every branch entry (including pruned-merged ones) by name via git, and dies on the first one whose ref no longer exists.Expected
modifyshould tolerate pruned merged branches — skip them the same wayviewandrebasealready do (e.g.✓ Skipping merged-a (PR #NNN merged)), and open the TUI over the remaining branches.Notes
gh stack viewandgh stack rebasework fine in this state; onlymodifychokes.sync --pruneproduces a stack state thatmodifycannot read..git/gh-stack.All reactions