What is the advantage of the rebase command in Mercurial?

Question

Compare to standard push/pull, what is the advantages of using the rebase command in Mercurial?

Solution 1

This post has a nice explanation:

The answer lies in rebasing. Rebasing is a technique made popular by git where you rewrite your not-yet-pushed patches so that they apply against the current remote tip, rather than against the tip of the repository you happened to last pull. The benefit is that your merge history shows useful merges—merges between major branches—rather than simply every single merge you did with the upstream repository.

Normal pull, merge, push sequence will create a number of commits that are not very useful in terms of the history of your repository. Rebasing helps to eliminate these.

Solution 2

If you do a pull-merge-push sequence and get the "merge" wrong you can always "backout" the "merge commit". Thus, you have an easy way of "undo-ing a push". I don't know if there is an equivalent easy way when using rebase.

Comments

[Tomislav Nakic-Alfirevic]

Clear answer, thanks Vincent. From my perspective, however, it makes me think that if that's all there is to it, it might not have been worth the trouble of adding a new feature and a new concept for users to think about.

[jk.]

you don't have to use rebasing, you can always branch and merge. iirc rebase is not enabled by default in mecurial

[Vincent]

@jk If it's not enable by default, is it a good idea to ask all the developers to enable it? What will happen if some one doesn't?

[Jay Peyer]

It shouldn't matter if it isn't enabled by all developers using a shared repo, as the rebase is done locally & doesn't result in anything special (just normal changesets).

[Vincent]

The rebase command will skip the merge operation thus no need to back-out from a bad merge.

[Guy]

I don't understand your comment.. My point is, using merge, it's easy to "backout" a bad push. How do you do that with rebase?

[Daniel Serodio]

It's not simply "a better way to merge" thou, see this heads-up post

[Vincent]

When using the rebase command, there is no merge operation. So it's not possible to have a "bad merge". If you do a push after rebase and it's not good you can always back-out.

[José F. Romaniello]

I totally agree with @Guy, rebase hides a merge and hides the order of events. When doing a rebase if there is a conflict, mercurial will allows you to fix the conflict but that operation will be "mixed" with the first commit of the rebased head. In the end you don't know if the revision broke something or the conflict resolution you made broke it.

[Vincent]

You're right José. I didn't see that one. But not sure that @guy was referring to that.