Duy Nguyen <pclouds@xxxxxxxxx> writes:
> I fail to see the point here. There are two different things: what we
> want to send, and what we can make deltas against. Shallow boundary
> affects the former. What the recipient has affects latter. What is the
> twist about?
do_rev_list() --> mark_edges_uninteresting() --> show_edge() callchain
that eventually does this:
static void show_edge(struct commit *commit)
{
fprintf(pack_pipe, "-%s\n", sha1_to_hex(commit->object.sha1));
}
was what I had in mind.
For a non-shallow transfer, feeding "-<boundary commit>" is done for
commits that we do not send (we do not do so for all of them) and
those that we know the recipient does have. Two different things
used to be the same, but with your suggestion they are not. Which
is a good thing but we need to be careful to make sure existing
codepaths do not conflate them and untangle ones that do if there
are any, that's all.
> As for considering objects before shallow boundary uninteresting, I
> have a plan for it: kill upload-pack.c:do_rev_list(). The function is
> created to make a cut at shallow boundary,...
Hmph, that function is not primarily about shallow boundary but does
all packing in general.
The edge hinting in there is for thin transfer where the sender
sends deltas against base objects that are known to be present in
the receiving repository, without sending the base objects.
--
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