Redundant Merges

[John Buckley]

Hi,

We are experimenting with Mercurial after a few years of working with
darcs. We have a "central" repo accessed via ssh with various
developers pulling/pusing to this repo.

If a developer with local (non-published) commits pulls other changes
from the central repo he is asked to merge these changes into his
local working directory, so far so good. What has surprised us is that
non-conflicting merges are dumped into his working directory as a new
change and must be re-committed. This results in a new, redundant
changeset in the log e.g.

@    1005:2551b0e24360,  tip 1003:9bae77eb1a76 1004:39bf49f5b2e0
2010-01-19 22:51 +0000, john at xxx.com
|\      * Merging PDF crop box fix from repo.
| |
| o  1004:39bf49f5b2e0,   995:a5b3024bd247  2010-01-19 19:47 +0000,
hamish at xxx.com
| |     * Fixed bug in double-click-to-zoom where PDF crop box has
non-zero offset.

<snip>

| |
o |  996:1e4550b27d2f,    2010-01-18 16:51 +0000, john at xxx.com
|/      * Adding mergejsstrings.py
|
o  995:a5b3024bd247,    2010-01-15 16:26 +0000, john at xxx.com
|       * Re-enabling basic analytics

Darcs would have handled this non-conflicting merge silently resulting
in just a single changeset (#1004) with no explicit merge necessary.
So my question is why doesn't Mercurial do this too? Why should we end
up with two identical changesets (#1004 & #1005) for a single original
commit? In a distributed environment we could end up with duplicate
(merge) changesets for most commits. Is there a way of making
Mercurial avoid this redundant merge, or of changing our working
practise to avoid this situation?

Thanks,

John