On Thu, Jun 6, 2013 at 7:25 PM, Junio C Hamano <gits...@pobox.com> 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.


> Replace the "lifo" field with an enum rev_sort_order, with two
> 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 <gits...@pobox.com>
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to