问题
We're currently working on the new version (version 2.0) of an application.
We have a customer running version 1.0 of the app who found a bug. We updated to the tagged changeset for version 1.0 and located and fixed the bug.
We committed the change which created a new head in our source tree.
The question is how best to merge this? Ideally I would want to merge it into the changeset that followed version 1.0. I don't want to merge it into the tip because the code where the bug was found doesn't actually exist anymore.
I realise I perhaps should have created a separate branch for "v1.0 bug fix".
Thanks, Ben
回答1:
When moving a change within a repository using merge it's all about the most recent common ancestor of the place you have the change and the place you want it. If before making this fix your repo looked like this:
[a]-[b]-[c]-[d]
with the 1.0 tagged changeset being [b] then you now have this:
[a]-[b]-[c]-[d]
\
-[e]
where the fix is in [e]. If that's the case then you just need to do this:
hg update d
hg merge e
hg commit
Then you'll have this:
[a]-[b]-[c]-[d]-[f]
\ /
-[e]-----
If on the other hand before making the changes your repo looked like this:
[a]-[b]-[c]-[d]
\
-[e]-[f]
where the 1.0 rag pointed to [f] then you now have this:
[a]-[b]-[c]-[d]
\
-[e]-[f]-[g]
with the fix in [g]. If you want to move the changeset [g] into [d] without bringing [e] and [f] along with it, there's no good way to do it. The not-so-good way available to you (called cherrypicking) is to use the hg export and hg import commands.
No workflow requires cherry picking, but avoiding it requires a little forethought. In that second case you would avoid it by making the fix not on the 1.0 series (as a child of [f]) but instead as a child of the most recent common ancestor of the two places you want that change. Since you want that change in both [d] and [f] you look for their most recent common ancestor and see it's [b] and make the change as a child of that using these commands:
hg update b
..edit..
hg commit
leaving you with this graph:
[a]-[b]-[c]-[d]
\
\--[g]
\
-[e]-[f]
this fix, [g] is a new head, and you can merge it into both [d] (2.0) and [f] (1.0) without any cherry picking at all. The commands for that would be:
hg update d
hg merge g
hg commit
hg update f
hg merge g
hg commit
and the resulting graph would be:
[a]-[b]-[c]-[d]--[h]
\ /
\--[g]----
\ \
-[e]-[f]-[i]
where [h] is your new 2.0 with the fix, and [i] is your new 1.0 with the fix.
Summary: you can always avoid cherry picking with forethought, but it's not the end of the world if you didn't
回答2:
It sounds like you have this:
[a]-[b]-[v1]-[c]-[d]-[v2]
\
-[fix]
and want to get rid of the extra head without merging any of the changes in [fix].
Option #1
The following commands will simple mark the branch closed, and it won't count as an extra head and be hidden from hg heads and hg branches commands:
hg update fix
hg commit --close-branch -m "closed branch"
Option #2
The following commands will "dummy merge" the extra head, throwing away any changes.
hg update v2
hg --config ui.merge=internal:fail merge
hg revert --all --rev .
hg commit -m "dummy merge"
the --config ui.merge=internal:fail flag prevents a merge tool from trying to merge any conflicts, but doesn't prevent files added to the other head from appearing, since there would be no merge conflicts with a newly added file. The revert will simply update all the files back to the first parent's state. You'll end up with:
[a]-[b]-[v1]-[c]-[d]-[v2]-[merge]
\ /
-[fix]-----------
but the content of [merge] will be the same as [v2].
Option #3
Yet another way to do a dummy merge:
hg update v2
hg debugsetparents v2 fix
hg commit -m "dummy merge"
This sets the working directory to v2, but then "fakes out" Mercurial that both v2 and fix are the parents and commits it as a merge.
来源：https://stackoverflow.com/questions/4959945/some-help-with-merging-legacy-branch-in-mercurial