Marking this as done-cbb.

The simple version is in crew as bc3dbdb1d430.

I still believe the interactive flag should be dropped and the caller be free to
use whatever merge tool it wants.

richlowe: you're right on both points. The simple version is:

diff --git a/hgext/imerge.py b/hgext/imerge.py
--- a/hgext/imerge.py
+++ b/hgext/imerge.py
@@ -120,7 +120,7 @@
         # this could be greatly improved
         realmerge = os.environ.get('HGMERGE')
         if not interactive:
-            os.environ['HGMERGE'] = 'merge'
+            os.environ['HGMERGE'] = 'internal:merge'
 
         # The filemerge ancestor algorithm does not work if self.wctx
         # already has two parents (in normal merge it doesn't yet). But

It passes --auto tests. I am not sure what happens if you try to merge symlinks,
but that would be a simplemerge issue and is probably not worse than "merge".

About the --auto stuff, I don't know the original intent and it's not clear to
me that --auto == non-interactive, rather than --auto == try to merge everything
(possibly interactively). The merge tool can already be set with $HGMERGE. IMHO,
the interactive bit should be removed from imerge.filemerge().

pmezard:
  Won't that lose the automatic aspect of imerge merge -a (it'll just run what
you have 
  configured, which may be interactive)

I think using the builtin simplemerge instead of calling merge(1) would work
(but haven't tried).  It's somewhat tempting to suggest that the new merge
framework gaining a .interactive property, and imerge using those tools where
.interactive == False in priority order (as appropriate) would probably be the
right thing (presuming here that simplemerge would be the default case there,
where nothing else was configured).

Brendan, could it be easy like the following ?

diff --git a/hgext/imerge.py b/hgext/imerge.py
--- a/hgext/imerge.py
+++ b/hgext/imerge.py
@@ -117,11 +117,6 @@
         (fd, fo) = self.conflicts[fn]
         p1, p2 = self.wctx.parents()
 
-        # this could be greatly improved
-        realmerge = os.environ.get('HGMERGE')
-        if not interactive:
-            os.environ['HGMERGE'] = 'merge'
-
         # The filemerge ancestor algorithm does not work if self.wctx
         # already has two parents (in normal merge it doesn't yet). But
         # this is very dirty.
@@ -131,10 +126,6 @@
             return filemerge.filemerge(self.repo, fn, fd, fo, self.wctx, p2)
         finally:
             self.wctx._parents.append(p2)
-            if realmerge:
-                os.environ['HGMERGE'] = realmerge
-            elif not interactive:
-                del os.environ['HGMERGE']
 
     def start(self, rev=None):
         _filemerge = filemerge.filemerge


It passes the unit test and a couple of tests. But I was using the extension for
the first time, and have no new style tools configured just the usual ui.merge
with a custom merge script.

Mercurial has a whole new file merging infrastructure (including a built-in
3-way merge tool) that imerge hasn't been updated to.

Also note that the bar for inclusion of extensions is much lower than core
functionality. Some of them are not far beyond proof-of-concept stage.

The imerge extension doesn't work right on Solaris because it
relies on having a tool called "merge" in the user's path, and
that's from GNU RCS and isn't a default part of a Solaris install.

The code in imerge.py (credit to Rich Lowe for finding this) is
this:

        # this could be greatly improved
        realmerge = os.environ.get('HGMERGE')
        if not interactive:
            os.environ['HGMERGE'] = 'merge'

It just overrides the $HGMERGE variable with 'merge'.  That won't
work on all systems.  Something better is needed here.  (Or Mercurial
install needs to depend on RCS installation ...)