On Thu, Jun 6, 2013 at 7:25 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > When sorting commits topologically, the primary invariant is to emit > all children before its parent is emitted. When traversing a forked > history like this with "git log C E": > > A----B----C > \ > D----E > > we ensure that A is emitted after all of B, C, D, and E are done, B > has to wait until C is done, and D has to wait until E is done. > > In some applications, however, we would further want to control how > these child commits B, C, D and E on two parallel ancestry chains > are shown. Most of the time, we would want to see C and B emitted > together, and then E and D, and finally A. This is the default > behaviour for --topo-order output. > > The "lifo" parameter of the sort_in_topological_order() function is > used to control this. After inspecting C, we notice and record that > B needs to be inspected, and by structuring the "work to be done" > set as a LIFO stack, we ensure that B is inspected next, before > other in-flight commits we had known that we will need to inspect, > e.g. E, that have already been in the "work to be done" set. > > When showing in --date-order, we would want to see commits ordered > by timestamps, i.e. show C, E, B and D in this order before showing > A, mixing commits from two parallel histories together. When "lifo" > is set to false, the function keeps the "work to be done" set sorted > in the date order to realize this sematics. s/sematics/semantics/ (or perhaps s/.../semantic/ ?) > But the name "lifo" is too tied to the way how the function implements > its behaviour, and does not describe _what_ is the desired semantcs. s/semantcs/semantics/ > Replace the "lifo" field with an enum rev_sort_order, with two > possible values: REV_SORT_IN_GRAPH_ORDER and REV_SORT_BY_COMMIT_DATE. > > The mechanical replacement rule is: > > "lifo == 0" is equivalent to "sort_order == REV_SORT_BY_COMMIT_DATE" > "lifo == 1" is equivalent to "sort_order == REV_SORT_IN_GRAPH_ORDER" > > Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx> -- 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