On 9/9/06, Linus Torvalds <torvalds@xxxxxxxx> 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
-
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