Probably a "simple" merge would be something like

hg up -C $first
HGMERGE=merge-nofail hg -y merge $second

where

---%<--- merge-nofail
#!/bin/bash
merge "$@"
exit 0
---%<---

In this case, to get what log -ps should have told me, I was able to: hg up -r
589fce7f22d3 (first merge parent), hg merge e02e5bec4be5 (second merge parent), then

hg di -r 7651ff356dd7 | diffstat -p1

to see the difference from the correct merge to the actual merge (note that
--reverse has no effect here!), which reveals that just c74356de6239 (a dir
deletion) was reverted, and hg up -C tip afterwards to clean up.

It would be nice if 'hg backout -s' could also be used to undo any evil effects
of a botched merge changeset.

The combined diff format looks interesting, but it does not immediately show you
what was done beyond what a mechanical merge would have done, since it is
cluttered with stuff which was resolved mechanically.

For an illustration of why I really want this feature, look at

http://hg.netbeans.org/main/contrib/rev/7651ff356dd7

which is a catastrophically bad merge (reverted some earlier changesets such as
c74356de6239), and quickly tell me what is wrong (hint: look at diff from second
merge parent) and how to fix it.

Another option is the "combined diff format" from git.

See http://www.kernel.org/pub/software/scm/git/docs/git-diff.html

+1 for this idea.

Exactly. Won't provide the prettiest possible diff, but it is straightforward
and at least shows you what was resolved and how. For example,

--- conflicted/file
+++ resolved/file
-<<<<<
-  x += 3
-=====
-  x -= 2
->>>>>
+  x += 1

I think the exact display of resolved conflicts is a secondary concern. The
primary issue is to immediately highlight merges that made unintentional changes.

I presume you propose to show conflict markers in the before portion of the diff?

...and of course the new flag should be used by hgwebdir when displaying diffs
for merge changesets. Continuous builders which display changelogs between
builds, especially with file lists, would also be well advised to use -s or even
-sM, and the notify extension could be enhanced to use the equivalent of -sM to
show only merge changesets with "interesting" diffs.

I would often like to see what a merge changeset "did".

If the changeset was created by the fetch command and no external merge resolver
tool was spawned (or if equivalently I or someone I really trust used the merge
command and committed without making any further edits), then the merge did
nothing of interest: created no new diff hunks. Of course the merge might still
be "interesting" if two people's changes to unrelated files or parts of files do
not in fact work together, but I will find that out later (compiling, running
tests, ...) rather than by actually reviewing diffs.

If on the other hand the merge resulted in a conflict which had to be manually
resolved, that is certainly interesting to review.

Or if, as often happens, a novice Hg user scrambled their working copy during a
merge with a series of Hg commands they did not understand and no longer
remember, then committed and pushed the result, the merge may have done various
odd things - even revert other people's work - but it is not obvious from
looking at the output of 'hg log' that this is so, and it is not clear how to
undo the effects. (You can 'hg backout' the merge changeset, but how do you then
remerge parents correctly, when they are marked as already merged?)

For these reasons, it would be nice to have some way of reliably seeing any
nonobvious effects of a merge changeset. This would be useful both for (1)
post-mortem diagnosis of bad merges, perhaps making it easier to correct the
problems; (2) reviewing outgoing changes that might include merges before you
push (see Issue28 for another approach). Even if you wanted to see individual
changesets, 'hg out -pvM' is not very safe because it will hide any merge mistakes.

Running 'hg log -p' on a merge produces useless (and misleading) information
because it is a diff against the first parent only, and running an explicit diff
from the second parent is not much better.

Proposed enhancement:

Add an option --diff-from-simplemerge (-s) which changes the patch display for
merge changesets. Rather than diffing against the first merge parent, Hg will do
an in-memory 3-way merge using a "simple" merge (one that leaves conflict
markers in place if necessary); and then diff from that simple merge result to
the actual merge changeset. This will display (1) additional work done to e.g.
make code compile after a merge, (2) botched and confused merges, (3) work done
to resolve merge conflicts.

When used with either -m or -M, -s will display merge changesets only if they
would have a nonempty diff from the simple merge result, even if -p is not given
(and undisplayed changesets are not counted toward any count specified by -l).
When used with -v, -s will also limit the listed files to those which would be
mentioned in the patch, even if -p is not given. It is an error to specify -s
without at least one of -m, -M, -p, or -v, as it would have no effect.