Re: [PATCH 2/2] connect: know that zero-ID is not a ref

From: Shawn Pearce <spearce@spearce.org>
Date: Sep 3, 2016, 02:03 UTC
Message-ID: <CAJo=hJtg1h1Zvu-TjMtDYVjPB2n0pihA18q3sHBPQ_ZA4dWRKg@mail.gmail.com>
In-Reply-To: <20160902201321.35egsg5l6r2fvrtw@sigill.intra.peff.net>

On Fri, Sep 2, 2016 at 1:13 PM, Jeff King <peff@peff.net> wrote:

Show 5 quoted lines

>
> Hmm. So since this is backwards-compatible, I'm not overly concerned
> with changing the client. But I wonder if you considered that the
> documentation is wrong, and that JGit should stop sending the extra
> capabilities line?

No, JGit needs to keep sending the capabilities^{} line in upload-pack if there were no refs advertised to the client. (If it advertises at least one ref it does not send this capabilities^{} line.)

Show 17 quoted lines

> In either case, there will still be breakage until _somebody_ upgrades
> (with your patch, until clients upgrade; with a JGit patch, until the
> server upgrades). So perhaps an interesting question would be: if we
> were writing this now, what is the correct behavior?
>
> For pushing, it is obviously useful to send capabilities even though
> there are no refs (because the client is going to send _you_ something).
> And that is why "capabilities^{}" exists; it is a receive-pack feature
> (that is actually implemented!), and the documentation (which came after
> the implementation) blindly mentioned it for upload-pack, as well.
>
> Is it useful for upload-pack? If we have no refs, there's traditionally
> been nothing to fetch. Perhaps that's something that could change,
> though. For example, there could be a capability to allow fetching
> arbitrary sha1s (we have allowTIPSH1InWant and allowReachableSHA1InWant,
> which obviously both require some refs, but allowArbitrarySHA1 does not
> seem outside the realm of possibility).

Its exactly these sort of extra capabilities. We run JGit in modes where "out of band" (e.g. URL or higher level protocol framing like an undocumented HTTP header) allows the fetch-pack client to say "do not send me advertisements, but I want to learn your capabilities". The fetch-pack client typically activates the allow-reachable-sha1-in-want feature and names specific SHA-1s it wants.

This allows the fetch-pack client to bypass a very large advertisement if it wants only a specific SHA-1 and doesn't care about the ref name its bound to, or reachable through.

This is also perhaps a stepping stone towards "client speaks first". If we can later standardize an HTTP query parameter or extra HTTP header, the server may be able to avoid sending a lot of ref advertisements, but would still need to advertise capabilities.