y...@google.com writes:

> From: Martin von Zweigbergk <martin.von.zweigbe...@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?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to