Re: [PATCH] submodule: Demonstrate known breakage during recursive merge

From: Heiko Voigt <hvoigt@hvoigt.net>
Date: Aug 24, 2011, 20:27 UTC
Message-ID: <20110824202721.GF45292@book.hvoigt.net>
In-Reply-To: <4E5558BB.4040307@kitware.com>

On Wed, Aug 24, 2011 at 04:02:03PM -0400, Brad King wrote:

Show 22 quoted lines

> On 8/24/2011 3:14 PM, Heiko Voigt wrote:
> > thanks for finding this subtle bug!
>
> Thanks for looking at it!
>
> On 8/24/2011 3:46 PM, Heiko Voigt wrote:
>> For the merge search we do not take the bases into
>> account so the outcome will not change.
>
> The test case creates history like this:
>
> >     b---bc
> >    / \ /
> >   o   X
> >    \ / \
> >     c---cb
>
> where b, c, bc, and cb all reference different submodule commits.
>
> Isn't the merge search asked to search for a descendant of "b:sub" and "c:sub"
> during the recursive part of the merge and then "bc:sub" and "cb:sub" during
> the primary merge?  Might those results be different?

The merge is quite simple. All it does is check whether both changes base->a or base->b point forward in the submodule. Then it checks whether a is contained in b or the other way around. This is the only case in which it will succeed automatically.

Supposing you merge bc into cb: If I understand the situation correctly, the above is done first with a := cb:sub, b := bc:sub, base := b:sub and then another time with base := c:sub.

For the suggestion part only bc and cb are taken into account. That is we search for the first commit in the submodule refs which contains both bc:sub and cb:sub.

>
> As for the UI part, I think the user would be interested only in the search
> results for the primary merge between HEAD and MERGE_HEAD.  Results from the
> intermediate merges might not make sense.

As stated above since bc:sub and cb:sub will not change in between two searches the result for the suggestion will be the same. What I meant was that the same result would be output twice (or more).

Cheers Heiko