From: Marco Costalba Date: Sun, 10 Sep 2006 03:49:47 GMT Subject: Re: Change set based shallow clone Message-ID: In-Reply-To: On 9/9/06, Linus Torvalds wrote: > > > > 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