Jonathan Nieder <> writes:

> Thomas Rast wrote:
>> The existing description reads as if it somehow applies a filter.
>> Change it to explain that it is merely about the ordering.
> [...]
>>              OPT_SET_INT(0, "date-order", &sort_order,
>> -                        N_("show commits where no parent comes before its "
>> +                        N_("sort commits such that no parent comes before 
>> its "
>>                             "children"),
>>                          REV_SORT_BY_COMMIT_DATE),
> I fear this wording tweak doesn't go far enough.  The above
> description seems to describe --topo-order just as well as
> --date-order.
> How about something like
>               N_("topologically sort, maintaining date order where possible"),
> ?  I haven't checked the code to see if that's accurate, though.

Same laziness here, as I never actually use show-branch.  However,
you're right, I missed that it also has --topo-order (with a much saner
message).  So I think we can safely assume that it's the same meaning as
for git-log:

>  - by default, commits are listed in commit date order (newest first)
>  - with --topo-order, they are topologically sorted in such a way as
>    to ensure that in cases like
>       ---1---2---4---7
>           \           \
>            3---5---6---8
>    (from git-log(1)), parallel tracks are not interleaved
>  - with --date-order, they are topologically sorted but less
>    aggressively, in particular matching commit date order in the
>    usual case that that is already topologically sorted.
> That would make --topo-order stronger than "show commits in
> topological order" --- it should say something like "sort trying to
> avoid breaking up lines of development".

Depending on how you look at it, the lines of development are kept
together purely by coincidence or algorithmic convenience...

Thomas Rast
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to