This is a duplicate of issue1459 and a fix applied in 3793802ea41b - setting
status to resolved

mercurial-1.1.2-3 has been submitted to updates-testing

I think mpm has applied a fix for this in his private branch. It was a very old
bug, now revealed by changes in the sample mergetool configuration. It will
probably not be released before the marts release.

Neal, I suggest that you just release a new package with the offending
filemerge.executable line disabled. The current Fedora package
mercurial-1.1.2-2.fc10.i386 without any mergetool configuration gives a
inconvenient user experience.

I suggest that when merge issue identified in msg8466 is fixed, we switch back
to installing mergetools.rc by default.  Then, a non-existent tool will not be a
problem.  Any objections (NOTE: this is talking about the fedora package)

I should have another merge to consider later today anyway, so I will test it
then. In the meantime, I've commented out the workarounds so that I'll get a
reminder. :-)

It looks like a duplicate of issue1459. Non-existing merge tools _are_ silently
ignored - as long as they don't have an absolute path. And recently an absolute
path was introduced, and that revealed the bug.

Could you try to remove your workarounds and change the line in mergetools.rc to
filemerge.executable=whateverwithoutslashes

That can perhaps explain why nbecker felt he had to disable the default config.

No, that is not the problem. Non-existing merge tools should be silently ignored.

But it seems like there is a problem - I am investigating ...

On FC8, the config is originating in /etc/mercurial/hgrc.d/mergetools.rc. The
problem is that the configuration for filemerge is completely inappropriate.

It seems to me that a bad mergetools.rc should not be installed unless the
packager really works to break the packaging. Renaming mergetools.rc to
mergetools.rc.sample seems like a good step, but it also seems like a good idea
to find some way for the default installation to work out of the box with
minimal packager intervention.

Might it make sense to ship multiple mergetool.rc samples, one for each major
platform?

This is on FC8. The RPM version is 1.1-1. Output of hg debugconfig (eliding
email addresses). Note this is output of debugconfig when my workaround is
commented out.

The problem is not that mergetools.rc is searching for all tools on all
platforms. The problem is that it is getting a completely borked answer. The
symptom is that running hg fetch (when a merge happens), hg merge, or hg resolve
**fails** with a complaint that the filemerge tool (actually, it gives the full
path shown below) cannot be found.

It is the total fail of merge that makes this one urgent to critical in my mind.


bundle.mainreporoot=/home/shap/HG/bitc-methods
email.from=Jonathan S. Shapiro <>
email.method=/usr/sbin/sendmail
extensions.hgext.fetch=
extensions.hgext.gpg=
extensions.hgext.patchbomb=
merge-tools.diffmerge.args=--nosplash --merge --title1=base --title2=local
--title3=other $base $local $other
merge-tools.diffmerge.checkchanged=True
merge-tools.diffmerge.gui=True
merge-tools.ecmerge.args=$base $local $other --mode=merge3 --title0=base
--title1=local --title2=other --to=$output
merge-tools.ecmerge.gui=True
merge-tools.ecmerge.regkey=Software\Elli\xc3\xa9 Computing\Merge
merge-tools.filemerge.args=-left $other -right $local -ancestor $base -merge $output
merge-tools.filemerge.executable=/Developer/Applications/Utilities/FileMerge.app/Contents/MacOS/FileMerge
merge-tools.filemerge.gui=True
merge-tools.gpyfm.gui=True
merge-tools.gvimdiff.args=--nofork -d -g -O $local $other $base
merge-tools.gvimdiff.priority=-9
merge-tools.gvimdiff.regkey=Software\Vim\GVim
merge-tools.gvimdiff.regname=path
merge-tools.kdiff3.args=--auto --L1 base --L2 local --L3 other $base $local
$other -o $output
merge-tools.kdiff3.fixeol=True
merge-tools.kdiff3.gui=True
merge-tools.kdiff3.regappend=\kdiff3.exe
merge-tools.kdiff3.regkey=Software\KDiff3
merge-tools.meld.gui=True
merge-tools.merge.checkconflicts=True
merge-tools.merge.priority=-10
merge-tools.p4merge.args=$base $local $other $output
merge-tools.p4merge.gui=True
merge-tools.p4merge.priority=-8
merge-tools.p4merge.regappend=\p4merge.exe
merge-tools.p4merge.regkey=Software\Perforce\Environment
merge-tools.p4merge.regname=P4INSTROOT
merge-tools.tkdiff.args=$local $other -a $base -o $output
merge-tools.tkdiff.gui=True
merge-tools.tkdiff.priority=-8
merge-tools.tortoisemerge.args=/base: $output /mine:$local /theirs:$other
/merged:$output
merge-tools.tortoisemerge.gui=True
merge-tools.tortoisemerge.regkey=Software\TortoiseSVN
merge-tools.xxdiff.args=--show-merged-pane --exit-with-merge-status --title1
local --title2 base --title3 other --merged-filename $output --merge $local
$base $other
merge-tools.xxdiff.gui=True
merge-tools.xxdiff.priority=-8
paths.default=ssh://hg@dev.eros-os.com//srv/hg/repo/bitc
paths.default-push=/dev/null
ui.editor=emacs
ui.username=Jonathan S. Shapiro <>

It surely -is- a configuration error as Mercurial has no internal knowledge of
-any- merge tools. Something somewhere is giving Mercurial the name 'filemerge'.

The possible places are: .hg/hgrc, ~/.hgrc, /etc/mercurial/*, and HGMERGE

Now Mercurial ships with a file called contrib/mergetools.hgrc that we recommend
packagers install in an appropriate systemwide place with the following stanza:

filemerge.executable=/Developer/Applications/Utilities/FileMerge.app/Contents/MacOS/FileMerge
filemerge.args=-left $other -right $local -ancestor $base -merge $output
filemerge.gui=True

Of course, none of this should take effect if the filemerge tool isn't found.

What rpm are you using? What is the output of "hg debugconfig"?


I just noticed that mercurial-1.1.2-2.fc10.i386 contains this change:

* Thu Jan 01 2009 Neal Becker <ndbecker2@gmail.com> - 1.1.2-2
- Rename mergetools.rc -> mergetools.rc.sample

I think that change is a bad idea; the purpose of contrib/mergetools.hgrc is to
have some sane default for packagers.


And yes, contrib/mergetools.hgrc intentionally searches for all tools on all
platforms. Why should that be a problem? How did you notice?

Beginning in 1.0 or 1.1 (I think 1.1), linux-based installations of hg started
trying to use "filemerge" as the default merge tool. Since filemerge is only
present on OS-X, this cannot possibly be the right thing to do on a linux platform.

This is urgent -- I might even go as far as critical -- because for Fedora (and
perhaps other linux) users the current status is that "hg merge" is broken in a
mysterious and unfixable way. Mysterious because it used to work. Unfixable
because there is no documentation (including none in the release notes)
describing what changes should be made to the hgrc file to fix this misbehavior.

After a week of head scratching (and I *did* know enough to immediately
recognize that this was a problem to solve in the hgrc file), I was able to work
around the misbehavior by adding:

[merge-patterns]
** = filemerge

[merge-tools]
filemerge.executable = /usr/bin/merge
filemerge.args = -A $local $base $other

Prior to this change, my ~/.hgrc did not have either a [merge-tools] or a
[merge-patterns] section at all, so this wasn't a case of misconfiguration.
Also, I did not have extdiff enabled or configured.

hg merge is something that really needs to work reasonably "out of the box", and
there is no reason I can think of that the existing behavior should have become
broken in the *absence* of a bad [merge-tools] or [merge-patterns] section.

It is possible that this is a Fedora packaging issue. Perhaps a filemerge
utility was added and Fedora failed to pick it up in their packaging. But this
does not seem likely, because the path that hg is attempting to use to run
filemerge is very clearly an OS-X path.

If this is an issue in trunk, then in my opinion it is important enough to
warrant a point release unless it has already been fixed in 1.2. If it turns out
that this is a Fedora packaging issue, let me know and I'll be more than happy
to light a fire there.