Re: [PATCH 0/8] ref-in-want

From: Jonathan Tan <jonathantanmy@google.com>
Date: Jun 19, 2018, 23:38 UTC
Message-ID: <20180619233817.140031-1-jonathantanmy@google.com>
In-Reply-To: <20180619231644.GB232723@google.com>

Show 12 quoted lines

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