Re: Automatic merge failed, fix up by hand

Junio C Hamano [off-list ref] 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?