Mercurial commit disappeared

We have switched to Mercurial recently. All had been going well until we had two incidents of committed changes going missing. Examining the logs has not made us any wiser.

Below is an example. The files committed at (1) revert to a previous state at (2) even though those files are not mentioned in the merge.

What can I check to understand why the files reverted?

There are three interesting changesets in this graph that can influence the (2) merge:

• Teal changeset: not shown, but looks like it's just below the graph. This is the first parent of (2)
• Blue changeset: number five from the bottom, labelled "Fix test". This is the second parent of (2).
• Common ancestor of the parents: also not shown, will be further below. Strangely, it looks like the teal changeset could be the common ancestor, but Mercurial will now allow you to make such a degenerate merge under normal circumstances.

When Mercurial does a merge, these are the only three changesets that matter: the two heads you merge and their common ancestor. In a three-way merge the logic is now:

ancestor  parent1  parent2  =>  merge
X         X        Y            Y (clean)
X         Y        X            Y (clean)
X         Y        Y            Y (clean)
X         Y        Z            W (conflict)

Read the table like this: "if the ancestor was X, and the first parent was also X and the second parent was Y, then the merge will contain Y". In other words: a three-way merge favors change and will let a modification win.

You can find the ancestor with

$ hg log -r "ancestor(p1(changeset-2), p2(changeset-2))"

where changeset-2 is the one marked with (2) above. When you say

The files committed at (1) revert to a previous state at (2) even though those files are not mentioned in the merge.

then it's important to understand that "a merge" is just a snapshot that shows how to mix two other changesets. The change made "in" a merge is the difference between this snapshot and its two parent changesets:

$ hg status --rev "p1(changeset-2):changeset-2"
$ hg status --rev "p2(changeset-2):changeset-2"

This shows how the merge changeset is different from its first and second parent, respectively. I'm sure the files are mentioned in one of those lists — unless the merge isn't the culprit after all.

When you examine the three changesets and the differences between them, then you will probably see that someone has to resolve a conflict (the fourth line in the merge table above) and picked the wrong file at some step along the way.