Optimal Merge Base selection

[John A Meinel]

Sorry, I hit send too soon...

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:
Me:    A - B - C - D - E - F
#            /   /
Other: G - H - I

Don't you want to recognize that G and H have been merged?

>
>
>>>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.

Specifically, per my example. Say I have some sort of a
integration-project, and I would like to merge in somebody's library. It
would be nice if after including their library, I could indicate that I
have merged it, so that in the future, I can keep up to date with their
library. Even patch it myself, and still pull the other persons mainline
patches.

In arch, I think you do this by copying the code into a subdirectory,
and then you "sync-tree" so you get all of their patches. Or you can
sync-tree their base-0, move the stuff into a subdirectory, and then
replay the rest of their patches.

I can't say for sure, because I've only done the opposite, where I break
apart an integrated project into sub projects, and then keep them in
sync with each other.


>>>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.

Well, I think tla handled it semi-ok, where it put the missing patch in
a temporary directory. I think it could be improved upon by actually
having it issue a "warning: missing file" rather than just creating a
directory and not informing you about it.

>
> Aaron

John
=:->
-------------- 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/3a56a124/attachment.pgp