3 ms·

What I sometimes do in this situation is just branch the second feature off of the first one's branch while it's in review, and then when the first one gets mer

What I sometimes do in this situation is just branch the second feature off of the first one's branch while it's in review, and then when the first one gets merged and/or updated, I rebase the second one. This is a bit of a pain because you have to keep the moving pieces in your head, but it usually works out cleanly enough. Of course you can't really put the second one up for review until the first one has been merged, but you can at least finish the implementation.

fosterfriends 5y ago
We tried manually rebasing too, before building Graphite. The challenge you face with manual rebasing is two parts: 1) If you update the bottom branch, you need to manually rebase each branch above it. That becomes brutal if your stack is >3 branches. 2) You cant perform a simple rebase-onto, because you'll copy all commits between the higher branch and trunk. You'd have to perform a three-way rebase, specifying the range of commits you'd like to copy onto the destination. This becomes infeasible by hand. Graphite-cli gets around this by tracking branch metadata and storing it in native git refs (https://graphite.dev/blog/post/y6ysWaplagKc8YEFzYfr https://graphite.dev/blog/post/y6ysWaplagKc8YEFzYfr). When you rebase a stack, it recursively performs the three-way merge to fix things up smoothly. On top of this, git provides no good mechanisms for submitting the stack. Graphite cli can submit/sync your whole stack as individual PRs, and can prune merged branches from the bottom of local stacks. Ends up coming together as a really powerful workflow :) The cli is open source here: https://github.com/screenplaydev/graphite-cli https://github.com/screenplaydev/graphite-cli, with docs here https://docs.graphite.dev/guides/graphite-cli https://docs.graphite.dev/guides/graphite-cli. There's also an active Slack community which helps provide input on new features and adjustments. Please let me know if you have any other questions!
- onekorg 5y ago
  > 1) If you update the bottom branch, you need to manually rebase each branch above it. That becomes brutal if your stack is >3 branches. I do this relatively easily with `--rebase-merges` flag.

fosterfriends 5y ago

We tried manually rebasing too, before building Graphite. The challenge you face with manual rebasing is two parts: 1) If you update the bottom branch, you need to manually rebase each branch above it. That becomes brutal if your stack is >3 branches. 2) You cant perform a simple rebase-onto, because you'll copy all commits between the higher branch and trunk. You'd have to perform a three-way rebase, specifying the range of commits you'd like to copy onto the destination. This becomes infeasible by hand. Graphite-cli gets around this by tracking branch metadata and storing it in native git refs (https://graphite.dev/blog/post/y6ysWaplagKc8YEFzYfr https://graphite.dev/blog/post/y6ysWaplagKc8YEFzYfr). When you rebase a stack, it recursively performs the three-way merge to fix things up smoothly. On top of this, git provides no good mechanisms for submitting the stack. Graphite cli can submit/sync your whole stack as individual PRs, and can prune merged branches from the bottom of local stacks. Ends up coming together as a really powerful workflow :) The cli is open source here: https://github.com/screenplaydev/graphite-cli https://github.com/screenplaydev/graphite-cli, with docs here https://docs.graphite.dev/guides/graphite-cli https://docs.graphite.dev/guides/graphite-cli. There's also an active Slack community which helps provide input on new features and adjustments. Please let me know if you have any other questions!

onekorg 5y ago
> 1) If you update the bottom branch, you need to manually rebase each branch above it. That becomes brutal if your stack is >3 branches. I do this relatively easily with `--rebase-merges` flag.