OK, did not work well at all; merging with the other head dropped a number of
the fixes. Looks like it is really necessary to import the fix diff on top of
the current head, not on top of the bad merge, which means dealing with bad
hunks in proportion to the amount of time that has passed since the bad merge.

One thing that seems to work well enough (not enough experience to be sure):

hg up parent1
hg merge parent2
# resolve any actual conflicts in a reasonable manner
hg di -g -r bad > /tmp/x.diff
hg up -C bad
hg import /tmp/x.diff
# merge with other heads normally

Example of such a fix:

http://hg.netbeans.org/main/rev/8eeea055384d

Merged with other head:

http://hg.netbeans.org/main/rev/0ee9ed9fbfe1

Still needed a little extra cleanup, not sure why:

http://hg.netbeans.org/main/rev/d46e518bf192
http://hg.netbeans.org/main/rev/46e66f0e8f33

No, I don't want to introduce new heads. The two original heads have already
been marked as merged (incorrectly), and there may be dozens of commits atop
that bad merge (including other temporary branches merged together). I'm not
sure what the suggested commands are intended to accomplish.

Don't you just want to make the merge parents heads again? I.e. hg revert
-rparent0 --all, commit, hg revert -rparent1 --all, commit?

If there are various changesets committed on top of the bad merge, it can get
more complicated to "rescue" them. Not sure how this should be done in a general
way. Conceptually you would want to reapply all the non-merge changesets on top
of the fixed merge, but this does not necessarily work so trivially.

It might be very useful to have a way to instruct Hg that one merge parent (say
the second) is not to be consulted when looking up the closest ancestor for each
file during a subsequent merge. Otherwise future merges can get confused by
looking around in and around the bad merge, and there is no clear way to clobber
it entirely. I would suggest e.g. 'hg merge --close trashrevn'; when the result
is committed, a metadata flag would be set, and the second parent (trashrevn)
would never be traversed when looking for closest ancestors of files.

When someone bungles a merge and winds up committing a completely wrong merge
changeset and pushing it to a public repository, it is hard enough to find it
(see Issue981), but even if you, it is not obvious how to revert it.

'hg backout' is probably wrong; you would have to pass it one or the other merge
parent, but this would result in a changeset identical to one merge parent which
claims it is a merge when it really isn't.

You can redo the merge (hg up -r $bad^1 && hg merge $bad^2 && hg ci) but there
are likely plenty of other changesets on top of the bad merge, so you need to
mark your good merge as somehow superseding the bad one. Perhaps you should
pretend to merge against the bad changeset and discard all changes? But I have
tried this and it does not seem to help; still results in massive strange
file-level conflicts when I try to merge with other heads (bos investigating).
Anyway this is hardly straightforward.

Would appreciate an option for 'hg backout' to undo the effects of a merge,
presumably requiring you to redo the merge properly, in such a way that you can
then merge against later changesets and have everything be "clean" again.