On Mon, Aug 13, 2012 at 1:05 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> y@xxxxxxxxxx writes:
>
>> From: Martin von Zweigbergk <martin.von.zweigbergk@xxxxxxxxx>
>>
>> '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?
I can't really say. I suppose the current patch is smaller (it can't
really get smaller than one line), but iterating over the arguments
the sequencer level might be more correct. Would the result be
different in some cases? I would be happy to add a test case at least,
although I'm not sure when I would have time to implement it in
sequencer.
To connect to the other mail I sent on this thread (in parallel with
yours), do you think "git cherrry-pick HEAD HEAD~1" should apply the
commits in the same order as "git cherry-pick HEAD~2..HEAD" (which
would give the same result if passed to 'rev-list --no-walk' for a
linear history) or in the order specified on the command line? I
couldn't find any conclusive evidence of what was intended in either
log messages or test cases.
--
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