> On 06/15, Jonathan Tan wrote: > > > > Supporting patterns would mean that we would possibly be able to > > eliminate the ls-refs step, thus saving at least a RTT. (Originally I > > thought that supporting patterns would also allow us to tolerate refs > > being removed during the fetch process, but I see that this is already > > handled by the server ignoring "want-ref <ref>" wherein <ref> doesn't > > exist on the server.) > > What's your opinion on this? Should we keep it how it is in v2 of the > series where the server ignores refs it doesn't know about or revert to > what v1 of the series did and have it be a hard error? I think it should be like in v2 - the server should ignore "want-ref <ref>" lines for refs it doesn't know about. And, after more thought, I think that the client should die if "fetch <exact-ref-name>" was not fulfilled, and ignore if a ref in "fetch <ref-with-wildcard>" was not fulfilled. The advantage of doing that is that we make the protocol a bit more tolerant to adverse conditions (e.g. a rapidly changing repository or an eventually consistent load-balancing setup), while having little-to-no effect on regular conditions. The disadvantage is that there is now one additional place where a failure can silently occur, but I think that this is a minor disadvantage. A naive script using "git fetch", in my mind, would assume that refs/heads/exact exists if "fetch refs/heads/exact:refs/heads/exact" succeeds, but would not assume that refs/heads/wildcard-something exists if "fetch refs/heads/wildcard*:refs/heads/wildcard*" succeeds, which fits in nicely with the die/ignore behavior I outlined above.
