Re: [PATCH] toposort: rename "lifo" field

On Thu, Jun 6, 2013 at 7:25 PM, Junio C Hamano [off-list ref] 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 <redacted>