Re: [PATCH 0/4] Re: cherry-pick and 'log --no-walk' and ordering

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

 



On Mon, Aug 13, 2012 at 10:05 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Martin von Zweigbergk <martin.von.zweigbergk@xxxxxxxxx> writes:
>>
>> ... so is a migration desired? Or just
>> change the default for --no-walk from "sorted" to "unsorted" in git
>> 2.0?
>
> I think the proper support for Johannes's case should give users
> more control on what to sort on, and that switch should not be tied
> to "--no-walk".  After all, being able to sort commits in the result
> of limit_list() with various criteria would equally useful as being
> able to sort commits listed on the command line with --no-walk.
> Think about what "git shortlog A..B" does, for example. It is like
> first enumerating commits within the given range, and sorting the
> result using author as the primary and then timestamp as the
> secondary sort column.
>
> So let's not even think about migration, and go in the direction of
> giving "--no-walk" two flavours, for now.  Either it keeps the order
> commits were given from the command line, or it does the default
> sort using the timestamp.  We can later add the --sort-on option that
> would work with or without --no-walk for people who want output that
> is differently sorted, but that is outside the scope of your series.

Makes sense. The shortlog example is a good example of sorting that
completely reorders the commit graph sometimes even making sense for
ranges. Thanks!
--
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]