How has "hg rebase" treated you so far? Have you discovered any bugs or gotchas? In what situations does it replace or complement mq?
+2
A:
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
2009-02-23 04:08:33
+3
A:
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.
Marcus Lindblom
2009-03-01 00:10:18
A:
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.
MartinP
2009-11-25 14:06:14