Re: Change set based shallow clone

"Marco Costalba" [off-list ref] writes:

On 9/10/06, Junio C Hamano [off-list ref] wrote:

quoted

"Marco Costalba" [off-list ref] writes:

quoted

quoted

quoted

                    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.

Not really.

To git-rev-list, which does not know how the visualizer uses the
data, what you are saying essentially means that it needs to
hold onto the data it parsed forever.  That's where my earlier
suggestion for visualizers to take advantage of the "windowing"
information comes from.  Since the chain depicted in the above
between E..F can be arbitrary long (and you would need to keep
track of information for B and C too, well, essentially
everything), that is unacceptable for rev-list if you do not
give it additional clue when it can discard that information.