Question

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

Answer 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