Re: Automatic merge failed, fix up by hand

[Junio C Hamano <junkio@cox.net>]

Junio C Hamano <junkio@cox.net> writes:

> I think merge-base, even though we attempted to fix it recently,
> is still confused and that is one of the reasons why you are
> getting this.
>
>     prompt$  git-rev-parse origin test-lenb-merge
>     81065e2f415af6c028eac13f481fb9e60a0b487b
>     702c7e7626deeabb057b6f529167b65ec2eefbdb
 -->8-- snip -->8--
>     +  Merge ../to-linus-stable/
>     ++ [ACPI] re-enable platform-specific hotkey drivers by default
>     +  ARM: 2851/1: Fix NWFPE extended precision exception handling
>     ++ [origin~34] intelfb/fbdev: Save info->flags in a local variable
>     prompt$  git-rev-parse origin~34
>     3edea4833a1efcd43e1dff082bc8001fdfe74b34

I spoke too fast.  merge-base is not giving you an incorrect
answer.  It just happens that the answer was way suboptimal.

The "[ACPI] re-enable platform-specific hotkey" is what it
chose, and my monkey guessing origin~34 happened to be better
merge base, but the logic used by merge-base is to pick the
latest (from wallclock wise) commit among several candidates,
and by that criteria it did the "right" thing.

In this case, the "right" thing was a wrong decision.  So we
probably should revisit how we choose the "best" merge base
among candidates.  I think "origin~34" which happened to be the
last one output by "git show-branch" was just an accident, not a
good rule to follow, so changing merge-base to use the one that
the other command shows the last would not be a good way to fix
this.

Probably the ideal way would be to give merge-base an option to
spit out all the candidates, and have the script try to see
which ones yield the least number of non-trivial merges.

Linus?