Why does Mercurial merge changeset contain items with no conflicts?

Question

Given this repository:

A1 - A2 - A3 - A4 - A5

.. you do hg pull which pulls in two more changesets from the remote repo, giving you two heads:

A1 - A2 - A3 - A4 - A5
        \
          B3 - B4

Let's say you do hg merge which gets you the M1 merge changeset:

A1 - A2 - A3 - A4 - A5----\
        \                   M1
          B3 - B4 --------/

So now an hg out will list M1...

If you do hg diff -c M1 you see:

Files that were added in B3 and B4
The diff for files that were modified in B3 and B4 for which there were no conflicts (files weren't modified in A3-A5)

Why does the M1 merge changeset include these items? And why would you need to push this changeset to the remote repository?

These changes are already in B3 and B4 which are in the remote repository. I understand why the merge changeset would include files which had changes in both A3-A5 and B3-B4 and resulted in a new merged version of the files. But I don't see why the changeset would include items where there aren't conflicts. Won't the push of M3 duplicate changes that are already in the remote repo?

Joel B Fant Joel B Fant · Accepted Answer · 2011-06-04T00:20:38

The simplest way I can think to put it is that B3 and B4 have A2 as the base on which their changes are built. To bring everything back to 1 head instead of 2, the merge represents a changeset that takes all of the changes in B3 and B4 and applies them on top of A5.

Another part of the reason it looks like that is you were on A5 when you merged B4. If you had been on B4 and merged, the merge would show A3, A4, and A5's changes on top of B4 instead (you would be on B4 when you called hg diff -c M1).

And no, pushing the merge won't really duplicate changes in any way you'd notice as redundant. The only time I've seen duplicate changes is when somebody rebases changesets that they've pulled from elsewhere or already pushed.

Why does Mercurial merge changeset contain items with no conflicts?

2 Answers