10

How has "hg rebase" treated you so far? Have you discovered any bugs or gotchas? In what situations does it replace or complement mq?

dbr
  • 165,801
  • 69
  • 278
  • 343
joeforker
  • 40,459
  • 37
  • 151
  • 246

3 Answers3

7

Rebase is very nice in the simple case (no or few merge conflicts), but if you have a lot of them it can be more trouble that it's worth, compared to the regular merge+commit:

Rebase changes your commits & alters history, and by default removes your original commits. This has a number of implications which are quite hairy if they hit you in a bad moment:

  • No way to see how you resolved conflicts. (i.e. diff between your original commit and the rebase, unless you elect to keep them and manually strip them before pushing)
  • No way to test each rebased revision merged ok, compiles and runs ok before committing them. You rebase, your commits change. (same exception as above)
  • If you are really doing distributed stuff and sharing/pulling from many sources, you must be extremely careful not to share any commits that you intend to rebase.
  • Additionally, if, in the above scenario, you accidentaly rebase then pull these pre-rebase-commits from someone, you get a double set of commits and need to 'hg strip' out one set of them. (I haven't tried to merge here.)

The problem is that rebase edits history. Which is what SVN does on 'update'. So, it's definitely something you could use, but if you have many outstanding commits and expect many conflicts, I recommend a merge instead.

Macke
  • 24,812
  • 7
  • 82
  • 118
  • Would these problems exist if you only allow the rebase to go through when there are no conflicts? I.e., what if you always hg rebase --abort rather than --continue, if given the option, and then go back and merge, but if you let the rebase go ahead when there are no conflicts? – Joshua Goldberg Jan 20 '12 at 17:46
  • @JoshuaGoldberg: Yes! Since no conflicts in a file does not imply that stuff works after merge. Altering different files that depend on each other can still cause problems, and that might be hard to detect afterwards. I've written an extension (RebaseIf) that automates what you suggest, but since it doesn't solve the fundamental problem, I'm not using it any more. Some people coming to Mercurial like it a lot though, but it provides a false sense of security so it's easier if you learn to love the merge. – Macke Jan 20 '12 at 21:20
3

The biggest advantage over MQ (Mercurial Queues) is that when you're pushing a queued patch onto a changed baselayer you end up with .rej files and have to manually fix the patch. With rebase you instead get a merge and your standard merge-rsolution tools are launched.

Ry4an Brase
  • 78,112
  • 7
  • 148
  • 169
0

I'm seeing problems with tags that point into the rebased branch.

.hgtags@XXXXXXXXXXXX, line 2: tag 'XXX' refers to unknown node

It seems as if the tags are not converted correctly.

deadfish
  • 11,996
  • 12
  • 87
  • 136
MartinP
  • 1