Optimal Merge Base selection

[John A Meinel]

Aaron Bentley wrote:
> John Arbash Meinel wrote:
>
>>>I've been thinking about how to select the merge base, and I think I'm
>>>realizing that it really doesn't matter all that much.
>
>
> The older your base is, the greater the chance that you've introduced
> subsequent changes.  Let's take a look at the history of a line
>
> revision A-1: AAA
> revision A-2: BBB
> revision A-3: CCC
> revision B-3: BBB
>
> The idea is that we have branch B being branched from A-2.  B-3 is a
> revision that didn't change the line we're interested in.  (Maybe it
> changed some other line).
>
> If you select A-2 as a base, your standard three-way logic produces
> CCC.  This is because wrt A-2, B-3 is unchanged, so A-3 is taken.

Thanks for the clarification.

...

>>>
>>>Me:    A - B - C - D - E - F
>>>#      |             /   /
>>>Other: + - G - - - -    /
>>>#      |     \        /
>>>You:   + - H - I - - /
>>>
>>>In this case, G is probably not as good of a merge base as A, but
>>>breadth-first-search would use G (to merge I into F).
>
>
> This is actually one of the properties of Baz merge-- it can pick a
> common base that's not in the revision history of either branch.
>
> I'm not sure why you think it's not as good a base.  In my view, G is
> the best-known base.
>

I can't really say how I felt, I can see G as a decent base.

...

>>>This change would mean trees with no real common ancestry, which only
>>>merged from a common group would not find their commonality. I mean
>>>something like this:
>>>
>>>Me:    A - B - C - D - E - F
>>>#            /           /
>>>Other: G - H           /
>>>#            \       /
>>>You:   J - K - L - M
>
>
>
> I did not intend to allow this case.  My plan was that when you merged H
> into C, H would not be considered an ancestor.

So if they did not have common ancestry before the merge, they don't get
common ancestry after the merge...
But what happens if you do:

>
>
>>>In this case, it would not find H as a merge base, since it is not along
>>>the main line of development for either tree.
>>>Though how 'H' got merged in, considering it doesn't share history, is
>>>left as an exercise for the user.
>
>
> Not to mention the guy who's trying to implement this stuff :-)
>
>
>>>Say somehow Me and You both merged a
>>>library (Other) into our main program. And then You update the library,
>>>and I want to merge your changes. In arch this could be done with a "baz
>>>replay M", which would even ignore any changes in M that did not effect
>>>shared code. I don't really know what "baz merge" would do. And now that
>>>it is after 1am, I can't think what it should do.
>
>
> To get the changes I introduced in M, you do baz merge M L.  However,
> the current conflict handler throws an exception when you try to do a
> merge and there's no file in THIS.  Suggestions for how to handle this
> conflict are welcome.
>
> Aaron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050710/5245c536/attachment.pgp