Re: [PATCH v2 2/8] upload-pack: implement ref-in-want

Brandon Williams [off-list ref] writes:

On 06/19, Junio C Hamano wrote:

quoted

Brandon Williams [off-list ref] writes:

quoted

I also think that we should keep this first implementation of
ref-in-want simple and *not* include patterns, even if that's what we
may want someday down the road.  Adding a new capability in the future
for support of such patterns would be relatively simple and easy.

I am all for many-small-steps over a single-giant-step approach.

quoted

 The
reason why I don't think we should add pattern support just yet is due
to a request for "want-ref refs/tags/*" or a like request resulting in a
larger than expected packfile every time "fetch --tags" is run.  The
issue being that in a fetch request "refs/tags/*" is too broad of a
request and could be requesting 100s of tags when all we really wanted
was to get the one or two new tags which are present on the remote
(because we already have all the other tags present locally).

I do not quite get this.  Why does it have to result in a large
packfile?  Doesn't the requester of refs/tags/* still show what it
has via "have" exchange?

Sorry Jonathan Tan said it much clearer here:
https://public-inbox.org/git/20180615190458.147775-1-jonathantanmy@google.com/

Hmph, it feels like that the real culprit in that illustration is
that the negotiation stops after seeing A, and assumes that the
chain leading to B and C need to be re-sent, without the parties in
the negotiation even discussing that lines of the history.  When you
say "want-ref refs/tags/*", intending to update remote-tracking refs
on your side with the result, shouldn't the protocol make sure that
the current state of the remote-tracking refs (i.e. B and C in the
example) is taken into account?  It does not quite sound like a
problem inherent to "want-ref refs/tags/*" or a like request; the
real cause of the problem seems to lie elsewhere, at least to me.

Thanks.