Discussion about merging

David Allouche david at allouche.net
Mon Jun 13 01:04:48 BST 2005

Aaron and I talked this issue out over IRC, and it turned out that we
actually agree in the end. This message is just for the record (and
because I do not feel like going to bed just yet).

On Sat, 2005-06-04 at 13:48 -0400, Aaron Bentley wrote:
> B cherry-picks the changes introduced by A-2.
> C cherry-picks the changes introduced by A-2.
> C merges B.  If A-2 is selected as a base, we have a problem: note that
> we're no longer talking about "the changes introduced by A-2", we're
> talking about the snapshot A-2 itself.  And most of the text of A-2 is
> gratuitously different from both C and B.

My mesh-merge definition would never pick A-2 as a base because its
patchset[0] includes A-1, and A-1 is not part of the intersection of the
patchsets of B and C.

        [0] patchset: the set of all merges and ancestors.

My definition only allows picking a BASE whose patchset is a subset of
the patchset of either tree being merged. The intention is to only allow
BASE to be an "ancestor", that is a commit whose history is fully
contained in both trees being merged.

That constraint effectively rules out using cherry-picks (that is,
revisions with an incomplete ancestry in either MINE or OTHER) as merge

In the end it turns out that my definition of mesh-merge subsumes
Aaron's definition and is a bit more generic.

> So what about rejects?  Let's say B and C each did a complete merge of
> A-2 and committed.  Then they reversed the textual changes of A-1 and
> committed again.  Now when they try to merge each other, it's legitimate
> that they get conflicts galore, because they really did both change the
> text that was introduced by A-1 into different things.

I wish it were possible to turn a merge into a cherry-pick post-facto.

The use case is:
      * B merged up to A-2, but A-1 is buggy and B want to push it back
        temporarily until A-3 comes out with a fix.
      * C merges with A-3.
      * B merges with C. The selected BASE should be A-0 so A-1 is
        restored along with the fix in A-3.

But that's another discussion entirely. And of course, it's possible to
avoid the hair by just stepping back before the A-2 merge and then doing
the A-2 cherry-pick.

                                                            -- ddaa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050613/84fab45f/attachment.pgp 

More information about the bazaar mailing list