Re: Another merge test case from the kernel tree.

> One more merge test case you would be interested.  What's most
> interesting about this commit is that it has three merge bases,
> not two.
> 
> commit c820884e4f35a40f88b787c3891a23d629ef6bfd
> Merge: aa2dca4563b0629ecd9d9994dfdf39f29ff1b43f 357d596bd552ad157a906289ab13ea6ba7e66e3d
> Author: Tony Luck <tony.luck@intel.com>
> Date:   Sun Sep 11 18:35:10 2005 -0700
> 
>     Auto-update from upstream
> 
> Attempt to reproduce this commit is somewhat troubling.  The
> 'stupid' strategy and git-resolve resolves cleanly and Tony's
> commit matches what 'git-resolve' does (obviously that is the
> algorithm everybody uses).
> 
> But the 'resolve' strategy says this is case #16 (and resolves
> this case differently but I think it is just by luck). This
> indicates that Tony _might_ have committed what he did not
> wanted to.  The path involved is arch/mips/kernel/offset.c.

>     [Tony, I think you've seen this one once in different
>     commit.  The terminology "case #16" means your merge has
>     more than one merge base candidates:
> 
>         Ancestor#1 -- -- Your tree
>                      X
>         Ancestor#2 -- -- Other tree
> 
>     and when a path in your tree matches Ancestor #i and the
>     same path in the other tree matches Ancestor #j (i!=j).
> 
>     The default git merge algorithm picks a single ancestor that
>     gives the least number of conflicting paths during the
>     merge, and compares your tree and other tree against it and
>     pick the one that changed since that ancestor if only one
>     side changed that path.  But in case #16, depending on which
>     ancestor we pick, the result may come from your tree or
>     other tree, and obviously we do a wrong thing with 50%
>     probability.
> 
>     Thie _could_ indicate that you _might_ be losing a reverted
>     you made in your line of development being overwritten by
>     what the other tree did.]