Problem
A branch often grows into two or more reviewable concerns, splitting these after the fact is tedious
Today it requires a manual operation: insert 1 PR above, cherry pick commits from PR1 to new PR2, rebase
If more than 1 split is required, it's even more error prone manipulations
Proposal
gh stack split [<new-branch>] [--at <commit>]
- Current branch keeps commits up to
<commit>
<commit> and commits above move to <new-branch>, inserted directly above the current branch in the stack (if some PR are already stacked above current PR)
- Branches already above are rebased onto the new layer; existing PRs keep their identity, the current PR's base is unchanged
Ideally, interactive mode lists the current branch's commits, user picks the split point and types the new branch name: this could happen in the gh stack modify view
Problem
A branch often grows into two or more reviewable concerns, splitting these after the fact is tedious
Today it requires a manual operation: insert 1 PR above, cherry pick commits from PR1 to new PR2, rebase
If more than 1 split is required, it's even more error prone manipulations
Proposal
gh stack split [<new-branch>] [--at <commit>]<commit><commit>and commits above move to<new-branch>, inserted directly above the current branch in the stack (if some PR are already stacked above current PR)Ideally, interactive mode lists the current branch's commits, user picks the split point and types the new branch name: this could happen in the
gh stack modifyview