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

[Jonathan Nieder <jrnieder@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