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
I thought that merging z into t in
r --- s --- t
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/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk