merge vs rebase -- rebase easier revert and better for packer

[atticus-sullivan]

Hi,
in #514 it was written that when rebasing, the history is better for packer and allows for much easier reverts. Just being curious why is that so?

• Well, merging just creates a new commit which introduces all the changes into the master branch so the history isn't that messed up, is it?
• And ok regarding revert, you most probably meant reverting a specific commit of the feature branch, right? (because reverting the whole branch is easier when merging it).

While the title may be a bit controversial, I definitely do not intend to start a whole discussion about merge vs rebase. I'd rather explore just these (two) facets (or moreover results) of the differences.

[L3MON4D3]

Well, I just heard it from @clason tbh :P

I'll try my best to explain my understanding of it:

Well, merging just creates a new commit which introduces all the changes into the master branch so the history isn't that messed up, is it?

I don't think that's true, the merge commit is empty in most cases, it only contains changes itself if there's a conflict between the master and the merged branch.
So merging leads to two separate histories, both of which have one common child, the merge-commit.
If master is merged into the other branch, the history would look something like this

| \    <- branch merged into master
|  |
| /|   <- master merged into branch
|  |
| /    <- branch diverges from master
|

I could imagine that packer finds the point where the branch diverged from master and lists all commits since then, and this could include some commits to master, which would be listed a second time.

Rebasing some branch on master effectively replays the commits of the branch on master, so the first commit of the branch points to (has as its' parent) the latest commit to master.

| \   <- branch merged into master
|  |
|  |
|  |
| /   <- rebased here 
|
| /   <- originally diverged here
|

Which is a much cleaner history

Reverting is probably easier without the merge since the reverted commit might modify a line that was changed in both master and the branch, and this change (on master) would now also depend on the merge-commit to be a complete unit of change, while in the rebased version the commit (in the best case) contains the modifications to be compatible with master.

Let's hope all that was correct, if it wasn't, this is the internet, so somebody will probably (hopefully) correct me :D

[L3MON4D3]

Ah, yes, ty for clarifying that 👍

[atticus-sullivan]

Ah yes, makes sense. Still don't get quite the packer part, but I don't really know what packer does (only that it exists ^^).
But I understand in case 2 a rebase can be cleaner and has benefits (e.g. the graph will look much cleaner and the merge is pretty straight forward (of course the rebase might be more difficult)). Thanks for explaining 👍

[atticus-sullivan]

Hm, can't find the button to mark this as answered (should be there but it isn't, even in the default light theme 🤷). But I consider it as answered 👍

[L3MON4D3]

You're welcome :)
About packer (I didn't elaborate very much there):
Packer can manages other plugins, and shows the new commits when a plugin is updated.
If a branch like the first diagram is merged it'll list the old changes from master that were explicitly merged into the branch again (this could include breaking changes and similar stuff, so potentially very confusing).

The button is gone for me too, no idea how :/

[L3MON4D3]

Ahh, probably because it's a general discussion, and not in Q&A :D