Julien Nitard <julien.nitard@m4tp.org> 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/