Re: Automatic merge failed, fix up by hand

From: Junio C Hamano <junkio@cox.net>
Date: Aug 24, 2005, 00:29 UTC
Message-ID: <7vek8kmb2a.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <7vzmr8mci2.fsf@assigned-by-dhcp.cox.net>

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

Show 7 quoted lines

> 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--

Show 6 quoted lines

>     +  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?