Mercurial - backup old merge

Question

I have a branch that looks like this:

A->B->C->D->...->Z ^ 1->2-^ 

where C is a merger of 2 and its ancestors.

Now I understand that I should not have merged. I could go back to B and transplant D ... Z , but this is a lot of work. Can I cancel JUST C ?

When I try hg backout --merge C , I interrupt: I cannot back up the merge change set.

These changes were transferred to the central repo, and I don’t want to change the history or anything else, I just want the reverse 2 , and he ancestors return to the common descendant with B

Answer 1

A little late, but I had the same situation a while ago. This worked for me smoothly:

 hg update -C -r "revision-C" hg revert --all -r "revision-B" hg commit -m 'UNDO blah blah whatever the merge did' hg update -C -r "revision-Z-or-whatever-the-current-head-is" hg merge -r "the-new-revision-created-in-step-3" 

Basically, this is exactly what the rollback does.

DISCLAIMER: Please note that if you later want to merge branch 1-> 2 again, you are likely to run into some problems. And "some questions" here are somewhat euphemistic. In fact, even BIG PROBLEMS may appear in this case. This scenario is dangerous mainly because problems can occur much later and completely unexpectedly. It is strongly recommended that you completely abandon branch "1" to avoid these risks. (Also see comments below.)

See the Crop Wiki Page for more information.

Answer 2

The merge is publicly accessible, and there are public commits in this merge

Suppose we have a published commit history (the top is the newest):

  rev5 | rev4 | rev3 <- unwated merge commit (rev2 to rev1) | \ wanted branch -> rev1 rev2 <- unwanted branch | | 

Instead, we would like to have an upper state, as if we had this story:

  rev5 | rev4 | wanted branch -> rev1 rev2 <- unwanted branch | | 

How to achieve this (step by step)

• Complete story after merging (rev4 - rev5) into one commit

   $ hg update -r rev3 # Update to merge commit $ hg revert --all -r rev5 # Revert to the newest commit $ hg commit -m "collapsed commits" # Create new commit ('rev6') rev5 | rev6 rev4 \ / rev3 | \ rev1 rev2 | | 

• Copy changes after merging ('rev6') to the desired branch ('rev1')

   $ hg update -r rev1 # Update to the last "wanted" commit before merge $ hg graft -r rev6 # Copy changes from 'rev6' (create 'rev7' commit) rev5 | rev6 rev4 \ / rev7 rev3 \ / \ rev1 rev2 | | 

• Create a backout commit

   $ hg update -r rev5 # Update to the top commit $ hg revert --all -r rev7 # Copy state 'rev7' $ hg commit -m "Reverted rev3 merge" # Create 'rev8' commit rev8 | rev5 | rev6 rev4 \ / rev7 rev3 \ / \ rev1 rev2 | | 

• Clear Temporary Fixes

   $ hg strip rev6 rev7 rev8 <- reverted 'rev3' merge | rev5 | rev4 | rev3 <- unwated merge commit (rev2 to rev1) | \ wanted branch -> rev1 rev2 <- unwanted branch | | 

Answer 3

Use the backup tool, but remember what you do:

• Update to merge change (C)
• Right click on this changeset -> click Backout
  • After you make a backup on a branch, you do not need to commit it immediately. It is better to check before that if there are (among the changes that occurred after choosing the Backout option) there are some changes from other branches that you do not want to backtrack. If so, clear them before committing.
• Click Commit
  • If you merge branch 1-2 (or the "numbered branch") into the AZ branch now (or later), you will lose all changes from the "numbered branch" to change set 2 (including) - this is what the warning in @Marvin answer about .
  • To avoid this, you need to distribute this backup to a "numbered branch" and make repeated changes (next steps).
• If the AZ branch is not a direct ancesstor of the "numbered branch", then find the first child branch between AZ and 1-2 and update the working environment to the end.
• Right click on the latest revision in AZ (= backout) -> click "Merge" with local
  • If there are more branches between AZ and 1-2 , repeat steps 4. and 5.
  • Do not merge anything into branch 1-2 .
  • Note. Always merge any branch only in the one from which it comes! Otherwise, you risk losing some changes after future mergers.
• Update to the end of the "numbered branch".
• Find all the files (in the file system) that were changed using backup and copy them to some temp directory.
• Right-click on the latest version of the numbered branch ancesstor → click "Merge" with the local
• Copy the files from step 7 back to the file system.
• Check the changes in worbench and discard any changes that are not related to branch 1-2 (for example, changes from versions D - Z ).
  • Unfortunately, this needs to be checked manually. But this is the only safe way to fix both branches.
• Click commit

Tip. . To be sure which files have been affected by any merge, right-click on this revision and select Diff to parent

This is basically the scenario that we used today when we find that one branch (which is still under development) accidentally merged with default (instead of another, which had the same color in the graph editor :). (Both of these branches pushed changes after this merge.) It may seem time consuming, but still better than a backup merge, and find numerous unexpected errors days (or weeks) later. (Own experience.)

Answer 4

You can use thg debugging tool.

• Update to merge change (C)
• thg backout
• Choose which parent you want to cancel (no matter which version for (2)). Note that you are actually choosing a dialog box in which the parent changes you want to save are not saved.
• Click "Next"
• Click Commit

This will create a new chapter that you will need to combine with Z or redirect to Z.

Answer 5

You can reset D to Z on B The reboot documentation even discusses some similar situations. This should be done with a single command.