Thomas Rast writes:
> Umm, have you looked at the algorithm I proposed?
> ...
> So really, this is only about modifying the algorithm that generates the
> existing order to allow for streaming output as it reads through
> history.
Sorry, I thought you were optimizing sort_in_topological_order()
Thomas Rast writes:
> I hope I got that right. The order of commits is still entirely
> determined by the choice of "any tentative source", but the algorithm
> should now stream nicely once the generation numbers are known.
Thanks for an intereseting read.
Even though generation numbers are no
Junio C Hamano writes:
> Thomas Rast writes:
>
>> However, suppose we knew generation numbers. I haven't actually looked
>> into the old threads again, but my understanding was that they are
>> numbers g(C) attached to each commit C such that
>>
>> g(C) = 1 + max(g(P) for P a parent of C) f
Thomas Rast writes:
> However, suppose we knew generation numbers. I haven't actually looked
> into the old threads again, but my understanding was that they are
> numbers g(C) attached to each commit C such that
>
> g(C) = 1 + max(g(P) for P a parent of C) for non-root commits
>
> g(C) =
Thomas Rast writes:
> Junio C Hamano writes:
>
> The topo order algorithm can be modified to take advantage of
> [generation numbers], in order to provide incremental processing:
>
> Let S be the set of tentative sources
>
> Let U be the set of vertices whose out-edges are no known yet
>
Junio C Hamano writes:
> Thomas Rast writes:
>
>> The right fix would be to dig up Peff's work on generation number
>> caching, and modify the algorithm to take generation numbers into
>> account.
>
> I think you are totally wrong here, unless you are talking about a
> generation number that is
On 08/16/2012 02:00 PM, Thomas Rast wrote:
Michael Haggerty writes:
On 08/16/2012 10:51 AM, Thomas Rast wrote:
I suppose the real problem is that the "true" ordering
is completely obvious as the one ordering that does not require
preprocessing, but ugly to specify in words. Perhaps we can bi
Thomas Rast writes:
>> Why not turn the behavior on its head:
>>
>> * Change the default behavior to be something well-defined, easy to
>> document, and convenient for humans, such as "topological order with
>> ties broken by timestamp" or "approximate timestamp order, but
>> respecting dependenc
Michael Haggerty writes:
> On 08/16/2012 10:51 AM, Thomas Rast wrote:
>> I suppose the real problem is that the "true" ordering
>> is completely obvious as the one ordering that does not require
>> preprocessing, but ugly to specify in words. Perhaps we can bikeshed a
>> little? How about
>>
>>
On 08/16/2012 10:51 AM, Thomas Rast wrote:
[...]
is misleading. I suppose the real problem is that the "true" ordering
is completely obvious as the one ordering that does not require
preprocessing, but ugly to specify in words. Perhaps we can bikeshed a
little? How about
By default, commit
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> We could remove it if you find it confusing.
>>
>> I think the original motivation that line was added was to help
>> people who see "git log" (without any frills) output for the first
>> time not to be alarmed when they see newer things first
Junio C Hamano writes:
> Thomas Rast writes:
>
> > But then the new description is wrong. It claims that children are
> > always before parents, which is not true in the face of clock skew.
>
> Thanks for sanity-check. Here is an updated one.
[...]
> ---topo-order::
> +--date-order::
>
Junio C Hamano writes:
> We could remove it if you find it confusing.
>
> I think the original motivation that line was added was to help
> people who see "git log" (without any frills) output for the first
> time not to be alarmed when they see newer things first: "In
> general, the "time" flows
Martin von Zweigbergk writes:
> On Wed, Aug 15, 2012 at 1:02 PM, Junio C Hamano wrote:
>> diff --git a/Documentation/rev-list-options.txt
>> b/Documentation/rev-list-options.txt
>> index 6a4b635..9404d08 100644
>> --- a/Documentation/rev-list-options.txt
>> +++ b/Documentation/rev-list-options.
On Wed, Aug 15, 2012 at 1:02 PM, Junio C Hamano wrote:
> diff --git a/Documentation/rev-list-options.txt
> b/Documentation/rev-list-options.txt
> index 6a4b635..9404d08 100644
> --- a/Documentation/rev-list-options.txt
> +++ b/Documentation/rev-list-options.txt
> @@ -578,16 +578,33 @@ Commit Orde
It was unclear what "--topo-order" was really about in the
documentation. It is not just about "children before parent", but
also about "don't mix lineages".
Reword the description for both "--date-order" and "--topo-order",
and add an illustration to it.
Signed-off-by: Junio C Hamano
---
Tho
16 matches
Mail list logo
