On Wed, Aug 24, 2011 at 04:02:03PM -0400, Brad King wrote: > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html