Programmer Humor

19589 readers

2179 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

Keep content in english
No advertisements
Posts must be related to programming or programmer topics

founded 1 year ago

MODERATORS

[email protected]

1113

Rebase Supremacy (programming.dev)

submitted 7 months ago by [email protected] to c/[email protected]

238 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 16 points 7 months ago (27 children)

I know this is a meme post, but can someone succinctly explain rebase vs merge?

I am an amateur trying to learn my tool.

[–] [email protected] 18 points 7 months ago (7 children)

Merge gives an accurate view of the history but tends to be "cluttered" with multiple lines and merge commits. Rebase cleans that up and gives you a simple A->B->C view.

Personally I prefer merge because when I'm tracking down a bug and narrow it down to a specific commit, I get to see what change was made in what context. With rebase commits that change is in there, but it's out of context and cluttered up with zillions of other changes from the inherent merges and squashes that are included in that commit, making it harder to see what was changed and why. The same cluttered history is still in there but it's included in the commits instead of existing separately outside the commits.

I honestly can't see the point of a rebased A->B->C history because (a) it's inaccurate and (b) it makes debugging harder. Maybe I'm missing some major benefit? I'm willing to learn.

[–] [email protected] 16 points 7 months ago* (last edited 7 months ago) (4 children)

I feel the opposite, but for similar logic? Merge is the one that is cluttered up with other merges.

With rebase you get A->B->C for the main branch, and D->E->F for the patch branch, and when submitting to main you get a nice A->B->C->D->E->F and you can find your faulty commit in the D->E->F section.

For merge you end up with this nonsense of mixed commits and merge commits like A->D->B->B'->E->F->C->C' where the ones with the apostrophe are merge commits. And worse, in a git lot there is no clear "D E F" so you don't actually know if A, D or B came from the feature branch, you just know a branch was merged at commit B'. You'd have to try to demangle it by looking at authors and dates.

The final code ought to look the same, but now if you're debugging you can't separate the feature patch from the main path code to see which part was at fault. I always rebase because it's equivalent to checking out the latest changes and re-branching so I'm never behind and the patch is always a unique set of commits.

[–] [email protected] 4 points 7 months ago (1 children)

For merge you end up with this nonsense of mixed commits and merge commits like A->D->B->B’->E->F->C->C’ where the ones with the apostrophe are merge commits.

Your notation does not make sense. You're representing a multi-dimensional thing in one dimension. Of course it's a mess if you do that.

Your example is also missing a crucial fact required when reasoning about merges: The merge base.
Typically a branch is "branched off" from some commit M. D's and A's parent would be M (though there could be any amount of commits between A and M). Since A is "on the main branch", you can conclude that D is part of a "patch branch". It's quite clear if you don't omit this fact.

I also don't understand why your example would have multiple merges.

Here's my example of a main branch with a patch branch; in 2D because merges can't properly be represented in one dimension:

M - A - B - C - C'
  \           /
    D - E - F

The final code ought to look the same, but now if you’re debugging you can’t separate the feature patch from the main path code to see which part was at fault.

If you use a feature branch workflow and your main branch is merged into, you typically want to use first-parent bisects. They're much faster too.

[–] [email protected] 2 points 7 months ago (1 children)

You're right, I'm not representing the merge correctly. I was thinking of having multiple merges because for a long running patch branch you might merge main into the patch branch several times before merging the patch branch into main.

I'm so used to rebasing I forgot there's tools that correctly show all the branching and merges and things.

Idk, I just like rebase's behavior over merge.

[–] [email protected] 4 points 7 months ago (1 children)

The thing is, you can get your cake and eat it too. Rebase your feature branches while in development and then merge them to the main branch when they're done.