On 9/9/06, Linus Torvalds <torvalds@xxxxxxxx> wrote:
- output all revisions in the normal non-topological ordering
- when git-rev-list notices a topological sort error, it outputs a
"FIXME" line, and restarts the whole thing - printing out the commits
in the newly fixed ordering - and does it right the next time around
Sorry, but I don't understand why you should restart the whole thing
instead of store away the FIXME commit and continue.
If you read my previous e-mail in this thread perhaps it is better
explained the whole idea.
Anyhow the basic is:
-git-rev-list starts outputting the data early (order is not guaranteed)
-before to mark for output a revision check if it breaks --topo-order
-if the above is true store the revision away and *do not send*
- at the end you get an early started steram of topological corrects
revisions without
preordering, just because you filter away the (few?) revisions that
are not in order.
The list you get is guaranteed to be in topo order although my not be complete.
- _then_ you send the missing revisions that where previously
filtered out. At this stage the receiver has already drwan the graph,
indeed it has start drwaing as soon as the first revisons arrived and
*very important* receiver used old and fast topo-order parsing code.
- finally the fixup routine at receiver's end updates the graph with
the info from the small set of out of order revisions filtered out
before and sent at the end (only this small set is sent at the end).
Sorry if it is not still clear, in the previous my e-mail in this
thread there is also a small example that could be useful.
Marco
-
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