Redundant Merges

[Mads Kiilerich]

John Buckley wrote, On 01/20/2010 01:45 PM:
> 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.
>    

No, they are not redundant. But they are probably usually not relevant 
to you.

> Darcs would have handled this non-conflicting merge silently resulting
> in just a single changeset (#1004) with no explicit merge necessary.
>    

Which is one scary thing about darcs, from a 
drank-the-whole-mercurial-kool-aid point of view.

> So my question is why doesn't Mercurial do this too?

Because core Mercurial consideres history immutable and guarantees that 
all previous committed configurations can be restored.

> Why should we end
> up with two identical changesets (#1004&  #1005) for a single original
> commit?

They are not identical. 1004 has the remote changes but not the local 
changes, while 1005 has both. That might be irrelevant in most cases, 
but it will save you if somebody makes a mistake and shit happens.

> 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?
>    

You could try http://mercurial.selenic.com/wiki/RebaseProject and hg 
pull --rebase. YMMV.


It is good practice to release often and pull and "merge" often, but it 
might not be relevant to do it after every changeset. And if you have a 
development process with feature projects where the changes are reviewed 
before "merging" then that will create a natural linearization of changes.

/Mads