Re: [PATCH 2/4] revisions passed to cherry-pick should be in "default" order
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 13, 2012, 20:05 UTC
- Message-ID
- <7vtxw6d0ct.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <50289e50.a19f320a.5d99.3fdfSMTPIN_ADDED@gmr-mx.google.com>
y@google.com writes:
Show 13 quoted lines
> From: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
>
> 'git cherry-pick' internally sets the --reverse option while walking
> revisions, so that 'git cherry-pick branch@{u}..branch' will apply the
> revisions starting at the oldest one. If no uninteresing revisions are
> given, --no-walk is implied. Still, the documentation for 'git
> cherry-pick --stdin' uses the following example:
>
> git rev-list --reverse master -- README | git cherry-pick -n --stdin
>
> The above would seem to reverse the revisions in the output (which it
> does), and then pipe them to 'git cherry-pick', which would reverse
> them again and apply them in the wrong order.I think we have cleared this confusion up in the previous discussion. It it sequencer's bug that reorders the commits when the caller ("rev-list --reverse" in this case) gives list of individual commits to replay.
So I think we are all OK with chucking this patch. Am I mistaken?