Re: reftable [v4]: new ref storage format

From: Jeff King <peff@peff.net>
Date: Aug 2, 2017, 17:18 UTC
Message-ID: <20170802171849.qwg36gahgrav3o25@sigill.intra.peff.net>
In-Reply-To: <CAD0k6qRTa6jSgEBBX1Ux5yg4QMMWPpyOGTa471cRhtzBaS-KjQ@mail.gmail.com>

On Wed, Aug 02, 2017 at 08:20:44AM -0400, Dave Borowitz wrote:

Show 8 quoted lines

> >> OTOH a mythical protocol v2 might reduce the need to scan the
> >> references for advertisement, so maybe this optimization will be more
> >> helpful in the future?
> 
> I haven't been following the status of the proposal, but I was
> assuming a client-speaks-first protocol would also imply the client
> asking for refnames, not SHA-1s, in which case lookup by SHA-1 is no
> longer relevant.

Good point. The hidden-refs thing Shawn described is a trick that would be used because the current protocol is so lousy. It's not clear how a stateless-rpc request would work, but in theory the follow-up requests could also say "hey, I'm only interested in refs/{heads,tags}" and the stateless server could limit is marking to that.

But that would still leave something like allowReachableSHA1InWant having to look at all refs (and I don't see why a client requesting by sha1 would give any limiting refspec at all). On the other hand, looking at the ref tips would probably be dominated by actually traversing the commits in most cases. Of course one could come up with a pathological case pretty easily (tons of refs, and people asking for submodules at tip commits).

So I do think there are cases where the optimization would help, but I still not sure how much. If it's an optional bit of the design, we at least have the option of just not generating if it turns out not to be useful. My only concern would be if we make other protocol sacrifices or complications to include it.

-Peff