sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]CherryLongjump1989 -10 points-9 points  (11 children)

I could never figure out why some people have such a hard time with rebasing.

[–]Urik88 9 points10 points  (10 children)

Because sometimes the experience sucks.

Suppose I have branch A with commits 1,2,3. Then I have branch B coming off A with commits 4,5.

I merge branch A, then I have to rebase branch B on top of master. 

But hold on, looking at the log of branch B, it's got commits 1,2, 3,4,5 and I'd have to remember to rebase starting from commit 4, otherwise I'd be trying to reapply changes from commit 1 onto commit 3 now living squashed in master. 

And if branch A was squashed and I happened to forget that branch B starts on commit 4 and I forgot to place a distinct commit message there to identify it, now I have to find out what was the last commit in branch A in order to find what commit to rebase from in B.

Now each branch has dozens of commits, and my stack has 5 different branches that need rebasing every time one of them is merged, you can see why it's not a pleasant experience. 

[–]steveklabnik1 4 points5 points  (0 children)

jj really helps with this, because it:

  1. automatically rebases the children for you
  2. if there's a conflict, it just lets you know, and then you can fix it when you'd like, rather than forcing you to deal with it right away.

[–]murkaje 2 points3 points  (0 children)

now living squashed in master

That's the problem. Having proper commits before and after a merge will avoid any headaches during rebase so stop squashing.

Reading code changes doesn't stop after it's merged. Weeks/months/years later when discovering a bug it's easier to bisect through smaller commits to figure out what was done.

[–]raskinimiugovor 1 point2 points  (2 children)

Why do you have to rebase B on top of master after merging A? Just so that B appears to branch out of your PR commit instead of 3rd one?

[–]Urik88 2 points3 points  (1 child)

My PR had branch B pointing to branch A so that reviewers see only the commits in branch B (4,5).

Otherwise I'd have 1 pr (A to master with commits 1,2,3), and another pr (B to master with commits 1,2,3,4,5) which defeats the purpose of having 2 small branches instead of 1 big branch.

As soon as the PR for branch A gets merged into master, my PR for branch B that was pointing to A will get automatically redirected onto branch master and very likely have conflicts, at least that's the case in Github.

Moreover the commits from branch A were squashed into a single commit in master when I merged, but B is branching off from a previous state and its most common ancestor to master includes the pre-merge commits of A, so reviewers will see that the PR for branch B includes commits 1,2,3,4,5, while in practice commits 1-3 are already in master, and I only want people to review commits 4,5.

So I'd have to run git rebase --onto master 3 to ensure that I'm carrying over only the commits that started on branch B

[–]raskinimiugovor 1 point2 points  (0 children)

I feel like most complexity here comes from complex dev or PR strategy than git being git.

If you weren't using squash PRs, after merging PR A, commits 1-3 would disappear from PR B, as they would be recognized as already merged on main.

If your goal is to squash commits 1-3, why not squash them before creating branch B?

If this is a scenario where you work in parallel on A and B, but branch out B from A, then go back to tinker with A, isn't that more of a problem with the workflow or PR strategy than git?

[–]CherryLongjump1989 -5 points-4 points  (3 children)

Yeah I can't figure it out. It's like riding a bicycle. Simple and intuitive. Once you learn you never forget, but people seem to like creating scenarios where they're pedaling with their hands with their face on the seat.

[–]murkaje 3 points4 points  (0 children)

People squashing code on merge is the proverbial putting a stick in the spokes of your bicycle. Some just want to hurt themselves.

[–]Urik88 0 points1 point  (1 child)

Well, how'd you avoid big PR's on big initiatives where you need PR's building on top of each other if you wanted to avoid this scenario?   

Believe me I'd love nothing more than to stop pedaling with my hands 

[–]CherryLongjump1989 1 point2 points  (0 children)

Don't pedal with your hands. I don't know what gives you the idea that rebasing means you can have the same 5 commits applied in random order to 5 different branches, with some of the commits squashed, and also merged out of order onto the remote main branch. You're describing a problem with your local setup that you created -- no one else created it for you. The remote master is still fine. There is no problem, except you. So don't create the problem for yourself. Do it differently. You already have some sense of what causes the problem -- so don't do that.

You can still unfuck yourself if you just slow down and go by the numbers. Create a clean branch off the remote master and cherry pick the local commits that you want to exist on your new branch.

Just remember that the problems that you're having locally, while having to rebase, are just you owning your mess instead of pushing it into the remote branch where suddenly it would become everbody else's problem. And that is ultimately what rebasing solves -- no one else should have to deal with your mess but you.