3 ms·

Yeah one pain point is if you squash your commits on PR merges, you'll have a situation where the branches look like: master: 1, 2, 3 feature-1: 1, 2,

Yeah one pain point is if you squash your commits on PR merges, you'll have a situation where the branches look like: master: 1, 2, 3 feature-1: 1, 2, 3, 4, 5, 6, feature-2: 1, 2, 3, 4, 5, 6, 7, 8 Then we merge feature-1 into master (numbers in parentheses indicate squashing): master: 1, 2, 3, (4, 5, 6) feature-2: 1, 2, 3, 4, 5, 6, 7, 8 Then say we have another commit to master: master: 1, 2, 3, (4, 5, 6), 9 feature-2: 1, 2, 3, 4, 5, 6, 7, 8 And now we need to rebase feature-2 onto master. We can't do a normal rebase because git will try to do: feature-2: 1, 2, 3, (4, 5, 6), 9, 4, 5, 6, 7, 8 Instead we have to do a slightly tricky maneuver where we rebase just 7, 8 onto master, getting: feature-2: 1, 2, 3, (4, 5, 6), 9, 7, 8 It's not impossible and you can memorize the process pretty easily, but I'd love a natural solution to this problem.

fosterfriends 5y ago
This is exactly the problem that graphite-cli solves (https://github.com/screenplaydev/graphite-cli https://github.com/screenplaydev/graphite-cli) It keeps track of branchs and their parents by storing a tiny bit of metadata in the native git refs. It uses that information to perform recursive rebases: https://github.com/screenplaydev/graphite-cli/blob/main/src/actions/fix.ts#L179-L229 https://github.com/screenplaydev/graphite-cli/blob/main/src/... It ends up working seamlessly - you just modify some branch, and then run `gt stack fix` to recursively rebase everything. (and then `gt stack submit` to sync everything to github :) docs here: https://docs.graphite.dev/guides/graphite-cli https://docs.graphite.dev/guides/graphite-cli
- hardwaregeek 5y ago
  Sounds great! I signed up for the waitlist. I’m always for ways to make version control more ergonomic and feature full
KptMarchewa 5y ago
I amend my commits. My PRs are always exactly one commit, so this problem does not exist.
- hardwaregeek 5y ago
  Great? I don't get comments like this. It's like responding to someone saying their Ford's mileage isn't great with "I use a Honda so this problem does not exist". Good for you but saying the problem doesn't exist for you isn't helpful.
ossopite 5y ago
to my knowledge the easiest version of this manoeuvre, if you still have feature-1, is git checkout feature-2 git rebase feature-1 --onto master rather confusing. is there a better way? edit: oh, you mentioned extra commits on master since the squash of feature-1. does that require two rebases? git rebase feature-1 --onto master-at-feature-1 git rebase master
- hardwaregeek 5y ago
  so assuming you have merged feature-1 onto master and squashed, you check how many commits have been made since feature-1 on feature-2 (in my prior example 2 commits of 7, 8) and do: git rebase --onto master HEAD~2
- lmm 5y ago
  > does that require two rebases? No. Just git rebase --onto=master feature-1 will do the right thing. (Personally I merge rather than rebasing to avoid this whole problem).

fosterfriends 5y ago

This is exactly the problem that graphite-cli solves (https://github.com/screenplaydev/graphite-cli https://github.com/screenplaydev/graphite-cli) It keeps track of branchs and their parents by storing a tiny bit of metadata in the native git refs. It uses that information to perform recursive rebases: https://github.com/screenplaydev/graphite-cli/blob/main/src/actions/fix.ts#L179-L229 https://github.com/screenplaydev/graphite-cli/blob/main/src/... It ends up working seamlessly - you just modify some branch, and then run `gt stack fix` to recursively rebase everything. (and then `gt stack submit` to sync everything to github :) docs here: https://docs.graphite.dev/guides/graphite-cli https://docs.graphite.dev/guides/graphite-cli

hardwaregeek 5y ago
Sounds great! I signed up for the waitlist. I’m always for ways to make version control more ergonomic and feature full

KptMarchewa 5y ago

I amend my commits. My PRs are always exactly one commit, so this problem does not exist.

hardwaregeek 5y ago
Great? I don't get comments like this. It's like responding to someone saying their Ford's mileage isn't great with "I use a Honda so this problem does not exist". Good for you but saying the problem doesn't exist for you isn't helpful.

ossopite 5y ago

to my knowledge the easiest version of this manoeuvre, if you still have feature-1, is git checkout feature-2 git rebase feature-1 --onto master rather confusing. is there a better way? edit: oh, you mentioned extra commits on master since the squash of feature-1. does that require two rebases? git rebase feature-1 --onto master-at-feature-1 git rebase master

hardwaregeek 5y ago
so assuming you have merged feature-1 onto master and squashed, you check how many commits have been made since feature-1 on feature-2 (in my prior example 2 commits of 7, 8) and do: git rebase --onto master HEAD~2
lmm 5y ago
> does that require two rebases? No. Just git rebase --onto=master feature-1 will do the right thing. (Personally I merge rather than rebasing to avoid this whole problem).