Junio C Hamano <[EMAIL PROTECTED]> 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? - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
