Re: [boost] [git] Mercurial?

Subject: Re: [boost] [git] Mercurial?
From: Martin Geisler (mg_at_[hidden])
Date: 2012-03-22 08:38:05

Julien Nitard <julien.nitard_at_[hidden]> writes:

>> It seems that everybody has heard of this magic... but nobody has
>> actually seen it, and nobody can remember where they read about it :)
>
> I do, in case somebody is interested. It's in the introduction to
> Mercurial wrote by Joel Spolski.that was posted here not so long ago.
>
> http://hginit.com/00.html paragraph "One more big conceptual difference".

Oh, yeah, that guide... :)

I'm afraid Joel didn't really know what he was talking about back when
he wrote that piece. Let me hurry and say that I *also* used to think
that Mercurial/Git/... would re-apply the changes made on the branches
when merging.

I thought that merging z into t in

        r --- s --- t
       /
  ... a
       \
        x --- y --- z

would mean applying the x, y, z diffs onto t. If that was true, then it
would make a difference if you have 10 or 1000 changes between a and z.

But it's not what happens in a standard three-way merge: it depends only
on (a, t, z). The history back to the ancestor is only used to resolve
renamed files so that foo.c in a can be merged with bar.c in z.

A related operation is rebasing. There the granularity of your changes
*does* make a difference. A rebase is a series of merges. Rebasing x:y
onto t would mean merging t and x to create x', then merging x' and y to
create y', and finally y' and z to create z':

        r --- s --- t --- x' --- y' --- z'
       /   .------------'       /      /
  ... a   /     .--------------'      /
       \ /     /      .--------------'
        x --- y --- z

You then delete the second parents of x' to z' so that you have:

  ... a --- r --- s --- t --- x' --- y' --- z'

Since you do repeated merges it can be easier to merge if you have
smaller changesets. Too small changesets can mean that you have to
resolve a conflict that is cancelled by a later changeset (imagine that
x makes a change that conflicts with t and y undoes the change again).

-- 
Martin Geisler
aragost Trifork
Professional Mercurial support
http://www.aragost.com/mercurial/