Repository navigation
Conversation
Folding a branch into its parent, or popping one out of a stack, leaves that branch's pull request open on GitHub for a branch that no longer exists locally. Like the stacks a reorder or move makes stale, that should be sorted out at the next submit rather than needing the network at the time. So the queue submit already works through for dissolving stacks gets a second list, pull requests to close, each with the comment to leave on it and the tip its branch had. Submit goes through them after the backend submit, closing each one and then deleting its remote branch. The order matters because GitHub closes every open pull request based on a branch that gets deleted, and it's the backend submit that moves the ones above onto the replacement. So a branch something is still based on is kept and its delete stays queued, a close that fails stays queued for next time, and an already closed one counts as done. The forge port gets ClosePR for this and the git client a leased remote branch delete.
When two branches in a stack really should have been one PR, the only way to merge them was by hand: reset one onto the other, delete a branch, fix up the stack metadata and then close the extra PR on GitHub. That's easy to get wrong, and the branches above end up thinking their parent is a branch that's gone. Fold does it for the current branch and its parent. By default the parent survives: its ref is fast forwarded to the current branch's tip, we switch to it (same commit, so local changes come along) and the current branch is deleted. With keep it's the other way round, the current branch takes the parent's place and base and the parent is deleted. The branch above only changes its recorded parent, since it already has every commit, so nothing gets restacked. The folded branch's open PR is queued to be closed at the next submit, with a comment pointing at the PR it went into, and a stack GitHub already knows is queued to be dissolved like a reorder does. It refuses before touching anything when the branch is at the bottom, isn't on its parent yet, or the parent is checked out in another worktree (its ref would move under that checkout).
Folding a branch into the one below it was one of the last things the README still sent you to gh stack modify for, followed by a restack and closing the leftover PR by hand. So git stack fold (and git fold) now does it for the current branch: the parent keeps its name and PR and you end up on it, or with --keep the current branch takes the parent's place instead. It prints which branch went into which and, when there's a PR to close, that it'll be closed at the next submit. Agents get the same thing as stack_fold with a keep option. The README, the MCP docs, the agent skill and the architecture notes cover it, and "What it doesn't do" is down to dropping a branch from the middle of a stack.
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.
When two branches in a stack should really have been one PR, the README still sent you to
gh stack modify, then a restack, then closing the leftover PR on GitHub by hand. Easy to get wrong, and the branches above end up thinking their parent is a branch that's gone.git stack fold(andgit fold) does it for the current branch and its parent. By default the parent keeps its name and PR: its ref is fast forwarded to the current branch's tip, you end up on it (same commit, so local changes come along) and the current branch is deleted. With--keepit's the other way round, i.e. the current branch takes the parent's place. Nothing needs restacking since the branches above already have every commit. It refuses before touching anything if the branch is at the bottom, isn't on its parent yet, or the parent is checked out in another worktree. Agents getstack_fold.Like reorder and move it stays offline, so the GitHub side waits for the next submit. The folded branch's PR is queued to be closed there, with a comment pointing at the PR it went into, and then its remote branch is deleted. That happens after the backend submit on purpose: GitHub closes every open PR based on a branch you delete, and it's the backend submit that moves those PRs onto the surviving branch. So if something is still based on it (after a
submit --down, say) the branch is kept and the delete stays queued for next time.git stack pop(coming next) uses the same queue.