Please check my thinking on bug 646979

[James Westby]

On Mon, 04 Oct 2010 17:01:01 -0500, John Arbash Meinel <john at arbash-meinel.com> wrote:
> On 9/29/2010 11:23 PM, James Westby wrote:
> > What merge package does is first merge the two upstream revisions
> > together, taking the tree from whichever has the highest version number.
> > 
> >   ---B---F
> >  /  /   /
> > /  / .-D--.
> > \ A-=      H
> >  \    `-E-`
> >   \      \
> >    C------G
> > 
> > Currently it will then just merge H in to G (the target). This can
> > generate conflicts, which are very, very confusing to users, as it's
> > incredibly hard to explain why they are getting them.
> > 

> Does merging D & E generate conflicts itself? It would seem that if
> merging to G generates conflicts, then you should have gotten a conflict
> in the intermediate stage as well. (offhand the best you can usually
> hope for is more understandable conflicts, unless you have a real
> 'criss-cross' merge and we are selecting a very poor base.)

It is not a real merge.

We create a new revision with D & E as parents, and the contents of the
later of the two (defined in terms of upstream version numbers). So, no,
there is no possibility of conflicts at this stage.

>   A
>  /|\
> E D B
> |\|\|\
> | H F C
>  \ \| |
>   \ I |
>    \  |
>     \ |
>      \|
>       G

> Now you have a genuine criss-cross. As the lcas are E and B (ancestors
> of both I and G that are not superseded by a more recent ancestor.)

> Just using 3-way merge (vs say --weave) I would expect this to conflict
> more than merging H => G, because of our specific base selection (when
> we find a criss-cross 3-way goes to the next base, which will be A,
> which then will try to merge (I-A) into (G-A).

That's unfortunate.

Is there a way we could use our increased knowledge about the revisions
involved to merge with a strategy that would make this situation better?

Would it be beneficial to have some concrete examples to try out?

Thanks,

James