On 9/10/06, Junio C Hamano <junkio@xxxxxxx> wrote:
"Marco Costalba" <mcostalba@xxxxxxxxx> writes: > >> > >> A <--- tip of branch > >> / \ > >> B E > >> | | > >> | F > >> | / > >> C > >> | > >> D > >> ... > >> > > Ok. What about something like this? > A, B, C, D, E, (-3, 1)F > > where -3 is the correct position in sequence and 1 is the number of > revisions before F to whom apply the -3 rule. That means F knows who its descendants are, and commit objects do not have that information, so while traversing you need to keep track of all the descendants yourself, doesn't it?
Yes! it is, but you do it in git instead of in the visualizer ;-) because I think in any case someone defenitly needs to keep track of it.
And how does that fix-up information help the user of the stream anyway? If I understand your model correctly, the model does not synchronously draw nodes as they are received,
Visualizers draw only what is on screen so when you start them they draw the first 20/30 lines only. And noramally git output it's faster then user scrolling so when user scrolls down revisions are already arrived.
track of what it has seen so far. When it sees F it can notice that its parent, C, is something it has seen, so it can tell F is wrong. It also knows that it has seen E and E's parent is F (which turned out to be at a wrong spot), so it can suspect E is also in the wrong spot (now, it is fuzzy to me how that chain of suspicion ends at E and does not propagate up to A, but let's think about that later).
Is it possible, in that case flicker will be involved, but it is very uncommon, so in the big amount of all other cases we have no flickering and early graph drawing. Becasue the worst that can happen on visualizer side is flickering we can accept a worst rare case to have a big adavantage (no latency and no flickering) on the (very) common case: "user scrolls to a given page when the corresponding revisions are already arrived and, in case, fixed up". 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