Re: [PATCH v2 2/2] connect: advertized capability is not a ref

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Sep 3, 2016, 00:37 UTC
Message-ID: <20160903003708.GJ14758@google.com>
In-Reply-To: <CAGZ79ka0VvXbkR+JYJwK9oyRzcsDXDoqKXyp4F+moDc4qDuv7w@mail.gmail.com>

Stefan Beller wrote:

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

>> I'd be more interested in the pain of this transition if there was a
>> concrete use case for "hide literally all refs, but still allow
>> fetches". Is that a thing that people do?

[...]

> Not to derail the discussion to much, but let's talk about protocol v2
> for a second:

Uh oh. ;-)

>     One of the ideas we floated around for protocol v2 would be exactly
>     that: the server advertises only a small portion (could be just master
>     or no branch eventually) with a capability "v2" and then the client
>     selects that capability and after that there comes protocol 2.

Sounds scary to me. What would happen when I try to clone a repository with a v1 client? I'd see nothing. I'd want at least a "master" branch with a README file (or an ERR packet?) saying "please update your client".

>     The advantage of this approach would be have a functional
>     v1 server still running, but the meat is found only in v2: e.g. via
>     v2 you can obtain all pull requests/changes or even wiki/meta
>     information stuff that would be too large to advertise in v1.

This sounds less scary, but it doesn't answer the question Peff raised. Wouldn't it still be typical to advertise at least one ref, which can contain a capabilities line?

However, another idea I think you've mentioned before on-list about changing the ref advertisement could answer it. Suppose that I always include the ref advertisement in my first reply, but I provide a capability saying that further requests to this server can use a different mechanism that skips the long advertisement.

Normally that would work great --- I only pay the cost of the large advertisement once, and from then on I can cache what the server told me about how it prefers to be contacted. Except what happens if this was a new repository and my first contact with the server was to clone that empty repository?

In that case, getting capabilities with the ref advertisement would benefit me.

Likewise for other capabilities that may come with such an empty fetch: for example the server could tell which unborn branch the HEAD symref points to.

Thanks, Jonathan