Brandon Williams <bmw...@google.com> writes: > On 06/19, Junio C Hamano wrote: >> Brandon Williams <bmw...@google.com> writes: >> >> > 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. >> >> > 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-jonathanta...@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.
