If somebody has merged branch B into branch A, but meant to merge A into B (so that the commit would be on branch B), is there a method I could use to get that merge (and all of it's descendents) into branch B? Besides redoing the merge, which was a considerable amount of work.
The following approach should solve your issue, but is not really 'clean'.
Update to branch B (just before the merge).
Start a new merge with branch A. To avoid any interactivity, you can use 'hg merge --tool internal:local'. The actual merging doesn't matter, as you'll use the results from your previous merge.
Revert to the previous merge: hg revert --all -r OLD_MERGE_CHANGESET
Commit the merge.
Use 'hg rebase' to move all your later commits on top of the correct branch.
Assuming that you’ve just committed the merge, or if not, that the merge changeset 1. has no children and 2. is the parent of your working directory, then:
hg branch B --force
hg commit --amend
Related
I am stuck in a scenario in which I have created a branch on Mercurial Workbench from a wrong parent branch. In other words I had to create a feature branch from parent : xxx and I have created it from parent : yyy.
Please note that I have also committed the changes, Is there any way I can either redirect my feature branch to xxx or I can delete the branch and re-create it with the same name (please note that having the same name is important) but this time I can create it from xxx.
I have exported the patches of my commits so after creating a branch even if my commits are lost I can import the patches again.
If you needed to change the branch name you would want hg graft (see Graft vs. Transplant). But since you don't want to change the name, you only want to redo the base of the commits, you want hg rebase.
See Hg: How to do a rebase like git's rebase and also In Mercurial what's the difference between hg graft and hg rebase. Note that rebase is an extension, but is a bundled one: you merely need to enable it.
Suppose I have two branches A and B. These two branches have been merged together outside of hg (manually I suppose). The merge itself is correct and the files exactly reflect the merge between branch A and B.
Is there a way to commit those files as a merge? I mean to make them appear in hg as if they were merged using hg and make the new commit have both branches as a parent?
One option is to do the merge, but tell hg that you really want that merge to fail. Then reset the files to the version you want and manually mark them as resolved.
hg -y merge --tool=internal:fail otherBranch
hg revert --all --rev thisBranch
hg resolve -a -m
Once you commit and you should be on your way.
See more details here
When using Mercurial, assume you are using a 'default' branch. You work by creating new branches from this and merging them back into 'default' (when your work on that new branch is finished).
After merging a new branch (call it 'myBranch') back into 'default', you actually decide you need to work on 'myBranch'. 'myBranch' has not since been closed. What is the best to go about working on 'myBranch'?
Merging of branch (in Mercurial) doesn't mean it will become closed|disappeared. Used ranch is permanent part of Mercurial changeset forever
Merge will not close branch, just remove HEAD of merged branch
Because Mercurial's history is DAG, you can always return (hg up CS-ID) to any entry (changeset) in it and start working from this point, adding new child changeset on commit
For named branches, branchname is CS-ID of HEAD of latest (topologically) changeset of this branch
For LTB "Cleanup" I used hg up Cleanup after each merge it to Default branch
Nothing extra to do. If you want to continue from the last commit in myBranch do:
hg checkout myBranch # checks out last commit in myBranch
...hack...
hg commit # creates a new commit on myBranch
If, instead, you want to re-open myBranch with whatever is currently on deafult (rare) you do:
hg checkout default
hg branch --force myBranch # says "next commit should be on branch myBranch and I don't care if there already was one"
...hack...
hg commit
You probably want the first.
I've stuck with a small Mercurial problem: I merged a branch A into a branch B and everything succeeded, but after that one of my teammates reverted the branch B back to pre-merge status.
Now I need to merge branch A once again into branch B, but I get the following error:
abort: merging with a working directory ancestor has no effect
How to solve the problem?
You can backout revision that reverted your branch B. This will create new changeset with inverted modifications that was applied in "revert" changeset.
I goofed up a merge. I'd like to revert then try again.
Is there a way to revert a merge before it is committed?
hg revert doesn't do what I'd like, it only reverts the text of the files. Mercurial aborts my second attempt at merging and complains original merge is still uncommitted.
Is there a way to undo a merge after an hg merge command but before it's committed?
hg update -C <one of the two merge changesets>
After you do hg merge, but before hg commit, your working copy has two parents: the first parent is the changeset you had updated to before the merge and the second parent is the changeset you are merging with. Mercurial will not let you do hg merge again as long as your working copy has two parents.
You have two options on how to proceed:
If you want to abort the merge and get back to where you started, then do
hg update -C .
This will update the working copy to match the first parent: the . always denotes the first parent of the working copy.
If you want to re-merge some files then do
hg resolve fileA fileB
This will re-launch the merge tools just as when you did hg merge. The resolve command is good if you find out at hg merge-time that your merge tools are configured badly: fix the configuration and run hg resolve --all. You can run hg resolve as many times as you want until you are satisfied with the merge.
Today there is hg merge --abort. See hg help merge.