Re: cherry-pick and 'log --no-walk' and ordering

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Martin von Zweigbergk <martin.von.zweigbergk@xxxxxxxxx> writes:

> On Fri, Aug 10, 2012 at 2:38 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> Martin von Zweigbergk <martin.von.zweigbergk@xxxxxxxxx> writes:
>>
>>> There is also cherry-pick/revert, which I _think_ does not really want
>>> the revisions sorted.
>>
>> Yes, I think sequencer.c::prepare_revs() is wrong to unconditoinally
>> call prepare_revision_walk().
>>
>> It instead should first check the revs->pending.objects list to see
>> if what was given by the caller is a mere collection of individual
>> objects or a range expression (i.e. check if any of them is marked
>> with UNINTERESTING), and refrain from going into the body of the
>> preparation steps, which has to involve sorting.
>
> Do you mean "has to involve sorting" as in "has to involve sorting in
> order not to break current users of e.g. 'git log --no-walk
> --branches'"  or "revision walking inherently involves sorting"?

Range limited revision walking, e.g. "git cherry-pick A..B D~4..D",
fundamentally implies sorting and you cannot assume B would appear
before D only because B comes before D on the command line (B may
even be inside D~4..D range in which case it would not even appear
in the final output).

Any caller that wants to retrieve the objects given from the command
line in the order the user gave it, e.g. "git cherry-pick A B C",
using setup_revisions() and without walking the history, must look
at revs->pending.objects without calling prepare_revision_walk().
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]