One of the reasons you cant use a simple rebase --onto is that you dont want to accidentally copy all downstack commits between the merge base and what you're restacking onto. The CLI tracks branch bases commits through git refs to ensure that restacking never duplicates commits.
>Re `git rebase --onto`, the open source CLI offers a recursive implementation to prevent you from having to carefully rebase each branch in your stack
Thanks - you've answered what I've been looking for and I'd prefer that this information was in the marketing copy.
I agree that this would be an useful feature. I don't think this is a product though - I don't see myself doing more than 3 or 4 stacked diffs when this functionality would really shine.
yes that’s a possibility too, but then the typical merge resolution rules should apply. If there are common areas modified that is going to incur a manual review. There’s no magic automation I’d really entrust to fixing that.
- https://docs.graphite.dev/guides/graphite-cli
- https://docs.graphite.dev/guides/graphite-dashboard
Re `git rebase --onto`, the open source CLI offers a recursive implementation to prevent you from having to carefully rebase each branch in your stack (https://github.com/screenplaydev/graphite-cli/blob/main/src/...)
One of the reasons you cant use a simple rebase --onto is that you dont want to accidentally copy all downstack commits between the merge base and what you're restacking onto. The CLI tracks branch bases commits through git refs to ensure that restacking never duplicates commits.