Which head to position on before doing a merge?

Question

Is there a head to prefer when doing a merge?

What I mean is this: I've got, say, old rev 1000. Meanwhile I did 234 commits and I'm at rev 1234. Now I need to go back to rev 1000 to implement a bugfix for a customer. I commit the bugfix, give the release to the customer, and have the commit 1235.

It's only a tiny change: affecting only one file.

At this point I have two heads: 1235 (whose parent is 1000) and 1234. Their common (grand-grand-...-parent) is 1000.

If I issue an hg merge followed by an hg status, I receive a gigantic list of changes.

However if I do first hg update -C 1234, followed by an hg merge and an hg status, then I only see my unique change (unless I'm mistaken as to what just happened).

Basically, doing this:

hg update -C 1234
hg merge  # (merging 1234 and 1235, my two only heads)
hg status

gives a different status than this:

hg update -C 1235
hg merge  # (merging 1234 and 1235, my two only heads)
hg status

So basically, I'm asking the status (hg status) after merging the two same heads, but the output of hg status seems to depends on the head I'm currently at.

Is this the normal behavior and, if yes, is there one head to "prefer" over the other?

Do both operation result in the same repository / source code state at the end?

Answer 1

Yes, they both result in the same end state. Merges are almost 100% symmetric in Mercurial. The only non-symmetric part is named branches:

hg update branch-a
hg merge branch-b
hg commit

will create a changeset on branch-a. Updating to branch-b first will create it on branch-b. You can change the branch of the merge commit by issuing hg branch before you commit, though, so the default branch name more like a suggestion.

However, in your case, I would definitely update back to revision 1234 and then merge the bugfix into this revision. They way I'm thinking of it is that you have a main line of development — this is where you're working on new features for the next release.

When you make a bugfix to an old version you update back, make the bugfix, and make a bugfix release to your customer. You've then created another (tiny) branch for the bugfix. The question about where to update to before the merge is now this:

• do I want to continue along the bugfix branch? If so, then stay at the bugfix and merge the main branch into it.

• do I want to continue along the main branch? If so, then update back to the main branch and merge the bugfix branch into it.

In this case it only makes sense to update back to the main branch — you want your bugfix together with the new features, and you want to add more features.

Think about the named branches I mentioned above — there you would do

hg update 1.x
# fix bug
hg commit
hg tag 1.3

to go back to the 1.x series of your software, fix the bug, and make a 1.3 bugfix release. When done, you want to merge with the default branch. Since the branch name is inherited from the first parent in a merge, it's most smooth to update to default first:

hg update default
hg merge 1.x
hg commit

That's the recommended way to do it in Mercurial.