しらいしななこ <nanako3@xxxxxxxxxxxxxx> writes:
>> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
