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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 11, 2016, 16:53 UTC
Message-ID: <xmqqfuvxarcc.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CACsJy8BRhuSOs96fonjBJ0ok6JZJ3CwLkDPCP_9QQdROZUVh8w@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

Show 9 quoted lines

> 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?