Thomas Rast tr...@inf.ethz.ch writes:
Junio C Hamano gits...@pobox.com 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
Thomas Rast tr...@inf.ethz.ch 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
Junio C Hamano gits...@pobox.com writes:
Thomas Rast tr...@inf.ethz.ch 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)
Thomas Rast tr...@inf.ethz.ch 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
Thomas Rast tr...@student.ethz.ch 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
On Wed, Aug 15, 2012 at 1:02 PM, Junio C Hamano gits...@pobox.com 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 @@
Martin von Zweigbergk martin.von.zweigbe...@gmail.com writes:
On Wed, Aug 15, 2012 at 1:02 PM, Junio C Hamano gits...@pobox.com 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
Junio C Hamano gits...@pobox.com 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
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com 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
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, commits
Michael Haggerty mhag...@alum.mit.edu 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
Thomas Rast tr...@student.ethz.ch 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
On 08/16/2012 02:00 PM, Thomas Rast wrote:
Michael Haggerty mhag...@alum.mit.edu 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.
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 gits...@pobox.com
14 matches
Mail list logo
