Re: [PATCH v2 1/4] toposort: rename "lifo" field

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Jun 9, 2013 at 7:24 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> The primary invariant of sort_in_topological_order() is that a
> parent commit is not emitted untile all children of it are.  When

s/untile/until/

> 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 (i.e. the --topo-order output).  The
> "lifo" parameter of the sort_in_topological_order() function is used
> to control this behaviour.  We start the traversal by knowing two
> commits, C and E.  While keeping in mind that we also need to
> inspect E later, we pick C first to inspect, and we notice and
> record that B needs to be inspected.  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.
>
> 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, possibly mixing commits from two parallel histories together.
> When "lifo" parameter is set to false, the function keeps the "work
> to be done" set sorted in the date order to realize this semantics.
> After inspecting C, we add B to the "work to be done" set, but the
> next commit we inspect from the set is E which is newer than B.
>
> The name "lifo", however, is too strongly tied to the way how the

s/the way//

> function implements its behaviour, and does not describe what the
> behaviour _means_.
>
> Replace this field with an enum rev_sort_order, with two possible
> values: REV_SORT_IN_GRAPH_ORDER and REV_SORT_BY_COMMIT_DATE, and
> update the existing code.  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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]