0

The good news is I haven't pushed any changes yet. I had working code which I then committed as changeset 3526. Then I did an hg pull and hg merge. While doing the merge, I screwed up.

I would like to revert back to changeset 3526. (The tip is currently at changeset 3640.) But in doing this revert, I would like to satisfy the following conditions:

  1. I want it to be as if I never did the hg pull and hg merge.
  2. I don't want any dangling heads or new branches.
  3. After successfully doing the operation, I want the hg log to only read up to changeset 3526, as if I never did the hg pull or hg merge.
  4. I don't want to create a new revision that matches 3526 -- I want to be back at revision 3526.

What operation should I use to accomplish the above? I'm aware that you can do similar things using hg update, hg revert, and hg clone. But I'm not sure what exact command I should use, especially since, in some cases, you end up creating dangling heads or new branches.

What's the exact command that I'm looking for?

ktm5124
  • 11,861
  • 21
  • 74
  • 119
  • Possible duplicate of [Is there any way to delete local commits in Mercurial?](https://stackoverflow.com/questions/2338986/is-there-any-way-to-delete-local-commits-in-mercurial) – StayOnTarget Oct 24 '18 at 11:37
  • Just a tip - you probably don't have to worry about whether pull has been used or not in this scenario. It is just a synchronization step. While you can certainly remove changes that came in from a pull, eventually you'll have to just pull again anyway and they'll come back. If its the order of changesets which is the real concern there, I recommend reading about rebase. – StayOnTarget Oct 24 '18 at 11:39

1 Answers1

1

If you really want to do just that, you can use hg strip. You may need to supply more than one revision argument, depending on precisely which changesets you brought in during your hg pull. (Clearly -r 3527 must be removed; whether it removes all subsequent revisions depends on whether they are all descendants of 3527. Using hg log -G can help to figure that out.)

In general, though, there's no need to back out of a pull operation. It only gains you something if you will (a) never pull from that repository again or (b) go into that repository and alter it so that a future pull from that repository does not obtain those changesets. So if you're unsatisfied with your existing merge, you can just strip the merge and try again. There is no need to fear multiple heads within a branch, as long as you know what you are doing with them.

(You should also be aware that your local sequential revision numbers, such as 3526, are specific to your repository. As long as that's the one repository you're working on/with, it does not matter: just keep it in mind if you log in to another system that has a repository that you're occasionally sharing-with, via pull or push.)

torek
  • 448,244
  • 59
  • 642
  • 775