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

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

On 8/24/2011 3:14 PM, Heiko Voigt wrote:

quoted

thanks for finding this subtle bug!

Thanks for looking at it!

On 8/24/2011 3:46 PM, Heiko Voigt wrote:

quoted

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:

quoted

    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