Jonathan Nieder <jrnieder@xxxxxxxxx> 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 trast@{inf,student}.ethz.ch -- 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