I had 3 change sets that I wanted to rebase on top of the latest revisions. Unfortunately, I selected only one of them to be rebased and so this did a merge. Is there any way I can either undo the rebase or change it so the other two change sets get rebased as well?
+1
A:
If it's the very last thing you did you can do a 'hg rollback' which is a one-level undo. If, however, you've done anything since that alters the repository state (push, pull, commit, etc.) then rollback won't help you.
If it's any consolation, merging is generally preferable to rebasing and a mercurial history with a lot of merges shows someone who is using mercurial to its fullest. :)
Ry4an
2010-10-14 02:11:25
Since my changes just added new files, instead of modifying existing files, I thought it would be worthwhile rebasing instead of doing a branch and merge. I suppose that it doesn't really matter much anyway
Casebash
2010-10-14 02:37:23
There's nothing "wrong" with rebasing, but for some reason some folks consider a linear history a "prettier" history, whereas I want a history that shows the real order in which things were done and sometimes that order is parallel. If you really need to you can always `clone -r ` your repo up to the point where your repo diverged and then move of the changes you wish you were linear using export and import or the functionally identical transplant extension. I'd just learn to live with the accurate history you have.
Ry4an
2010-10-14 02:47:08
+1
A:
Assuming you haven't pushed it to another repo for others to grab, then you can put those changesets anywhere on the graph you want. You can move changesets with hg rebase and prune changsets and their descendents with hg strip.
Both strip and rebase save "undo" information as bundle files in your .hg/strip-backup/
Note that neither strip nor rebase are enabled by default with mercurial. You need to enable them in the .hgrc file.
Mark Borgerding
2010-10-14 04:16:49