Re: Change set based shallow clone

From: Junio C Hamano <junkio@cox.net>
Date: Sep 10, 2006, 05:46 UTC
Message-ID: <7vejukuvcy.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <e5bfff550609092214t4f8e195eib28e302f4d284aa@mail.gmail.com>

"Marco Costalba" <mcostalba@gmail.com> writes:

Show 30 quoted lines

> On 9/10/06, Junio C Hamano <junkio@cox.net> wrote:
>> "Marco Costalba" <mcostalba@gmail.com> 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.

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.