4 ms·
The docs for the CLI and dashboard go into some more depth - might be what you're looking for? - https://docs.graphite.dev/guides/graphite-cli https://docs.gra
by fosterfriends 5y ago
The docs for the CLI and dashboard go into some more depth - might be what you're looking for?
- https://docs.graphite.dev/guides/graphite-cli https://docs.graphite.dev/guides/graphite-cli
- https://docs.graphite.dev/guides/graphite-dashboard 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/actions/fix.ts#L179-L229 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.
- dv_dt 5y agoAs far as I’ve used it, git rebases ignore duplicate commits.
- KptMarchewa 5y agoThey are not duplicate if you change something (like, using amend) in one of the preceding branches.
- dv_dt 5y agoyes 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.
- KptMarchewa 5y ago>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.