Re: Change set based shallow clone

From: Marco Costalba <mcostalba@gmail.com>
Date: Sep 10, 2006, 03:49 UTC
Message-ID: <e5bfff550609092049t5e016cacr2502ce81bbb6489e@mail.gmail.com>
In-Reply-To: <Pine.LNX.4.64.0609091256110.27779@g5.osdl.org>

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

Show 16 quoted lines

>
>
>
> The example is
>
>                     A           <--- tip of branch
>                    / \
>                   B   E
>                   |   |
>                   |   F
>                   | /
>                   C
>                   |
>                   D
>                 ...
>

Ok now it' clear, thanks. But anyhow I think that it should be possible to avoid the check and reordering on the receiver side.

Suppose for a moment to split the graph drawing from the sequence reordering problem, suppose for a moment that receiver does do not draw the graph immediately.

As you described, in our case git-rev-list sends the following sequence: A, B, C, D, E, F

instead git-rev-list --topo-order would have sent something like A, E, F, B, C, D

Now I ask, is it possible to have a sequence (without latency) like A, B, C, D, (-3)E, (-3)F

where, in case of not topological correct revisions, git-rev-list gives the hint on the correct position in sequence (3 revs before in our case) where the revision would have been if the sequence would have been --topo-order ?

This saves all the checking and reordering on the receiver side and guarantees consistent results on different implementations of git visualizers because the --topo-order algorithm logic is computed in git rev-list only.

The visualizers could be sequence order agnostic, i.e. receivers can handle --topo-order or --date-order sequences or any other kind of sequence with the same code, simply they recreate the sequence in the way git-rev-list tells them.

Marco