Re: "git log --first-parent" shows parents that are not first

From: Junio C Hamano <gitster@pobox.com>
Date: May 11, 2008, 18:44 UTC
Message-ID: <7vd4ns3cll.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <200805110706.m4B76eLE006432@mi0.bluebottle.com>

しらいしななこ  <nanako3@bluebottle.com> writes:

Show 21 quoted lines

>> The result given by "git log --first-parent" ('next' version) is
>> unexpected to me.
>>
>>   % git rev-parse origin/next
>>   4eddac518225621c3e4f7285beb879d2b4bad38a
>>   % git log --abbrev-commit --pretty=oneline --first-parent origin/next^..origin/next
>>   4eddac5... Merge branch 'master' into next
>>   1f8115b... Merge branch 'maint'
>> ...
>>   921177f... Documentation: improve "add", "pull" and "format-patch" examples
>>   c904bf3... Be more careful with objects directory permissions on clone
>>
>> I asked for the log between one commit before the tip of "origin/next"
>> and the tip of the branch, following only the first-parent links.
>> v1.5.5 is not broken and shows the expected result:
>>
>>   % ~/git-v1.5.5/bin/git log --abbrev-commit --pretty=oneline --first-parent origin/next^..origin/next
>>   4eddac5... Merge branch 'master' into next
>
> Could you please revert d9c292e8bbd51c84cb9ecd86cb89b8a1b35a2a82?  With
> that patch reverted from 'next', the problem disappears.

That's d9c292e (Simplify and fix --first-parent implementation, 2008-04-27) by Stephen.

I know that the alleged "fix" works around a corner-case, a fast-forward situation that was artificually recorded as a merge, but if the "cure" breaks a normal case like this, it is worse than the disease.

Stephen, do you have a fix?