Re: Change set based shallow clone

From: Marco Costalba <mcostalba@gmail.com>
Date: Sep 9, 2006, 18:04 UTC
Message-ID: <e5bfff550609091104s3709b82fld3057a07a84ae857@mail.gmail.com>
In-Reply-To: <Pine.LNX.4.64.0609091022360.27779@g5.osdl.org>

On 9/9/06, Linus Torvalds <torvalds@osdl.org> wrote:

Show 8 quoted lines

>
>
>  - 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