Re: [BUG?] fetch into shallow sends a large number of objects

[Junio C Hamano <gitster@pobox.com>]

Duy Nguyen <pclouds@gmail.com> writes:

> Well, assume again that F and G are ref heads, and their respective
> distance to C and D are the same (like the below graph), then "fetch
> --deptch=<distance>" can mark C and D as shallow cut points because
> --depth traverses from refs until the distance is met, it does not do
> total exclusion ^C like rev-list.
>
>        --- B ---- C ---- H ---- F
>           /      /
>      --- D ---- E ---- G

Hmph, so we do not realize that D is reachable from C because we do
not even look at the parents of the latter.  Is there a remification
that breaks the proposed mental view coming from this?

Let me think aloud.  Later when we fetch again (without asking to
change the depth but without refusing an unsolicited depth change),
a fetch of history that lead to descendants of F or G will still not
realize that C and D are related, because the traversal down to C
would stop there without noticing that E is reachable from C.  That
won't break.  If the tips of the history have been rewound and now
points at the tips of a history that is forked before B and D (let's
say the new tip to replace G is Z), would that be a problem?  The
side that does have the full history would notice that the fork
point X is an ancestors of cutoff C and D, and can tell that the
side-branch proper, Y and Z, are interesting but X is where their
truncated history must stop.

        --- B ---- C ---- H ---- F
           /      /
 -- X --- D ---- E ---- G
     \
      Y --- Z

While doing so the side that originally had C and D as the cutoff
would be told that now X is also a cutoff.  In general, because the
side that has the full history and gets fetched would not have to
know about _all_ the refs and objects the fetching side has, so if
it didn't learn about the shallow side still having G, it wouldn't
be able to say that D is no longer an interesting cutoff, but would
that be a problem?  The side with full history should also be able
to notice that E can also be added as a cutoff.  Would that be a
good thing to do?  If so, perhaps we should have done that when the
original history was shallowing cloned with depth=2 in your picture,
perhaps?  After all, even though the shallow side may not know C and
D are related, the side that supplied the truncated history knows,
so after depth traversal finds C and D, it perhaps can postprocess
it to realize C and E is the set that should be sent as the cutoff?