Re: [PATCH 06/14] remote.h: add get_remote_capabilities, request_capabilities
- From
David Turner <dturner@twopensource.com>
- Date
- May 3, 2016, 21:21 UTC
- Message-ID
- <1462310486.4123.81.camel@twopensource.com>
- In-Reply-To
- <20160503053337.GA17986@sigill.intra.peff.net>
On Tue, 2016-05-03 at 01:33 -0400, Jeff King wrote:
Show 36 quoted lines
> On Mon, May 02, 2016 at 02:57:43PM -0400, David Turner wrote:
>
> > On Fri, 2016-04-29 at 16:34 -0700, Stefan Beller wrote:
> >
> > > +const char *known_capabilities[] = {
> > > + "multi_ack",
> > > + "thin-pack",
> > > + "side-band",
> > > + "side-band-64k",
> > > + "ofs-delta",
> > > + "shallow",
> > > + "no-progress",
> > > + "include-tag",
> > > + "multi_ack_detailed",
> > > + "allow-tip-sha1-in-want",
> > > + "allow-reachable-sha1-in-want",
> > > + "no-done",
> > > +};
> >
> > I wonder if it is possible to not repeat the list from upload
> > -pack.c?
> > It seems unfortunate to have to add the same string in two places
> > whenever you add a capability.
>
> I think that in general, we'd stop adding capabilities to v1. If you
> have a client which speaks the new capability, then it should also be
> speaking the new protocol. That's not strictly true if other non
> -git.git
> implementations want to learn capability X but not protocol v2, but I
> think in practice it's not an unreasonable world view.
>
> I guess there may be a grey area for a while, though, where even
> v2-capable clients don't end up speaking it, because they don't yet
> know
> that a particular server can handle it. So any capabilities added in
> that grey area may want to go to both v1 and v2.OK, but then there should be one list per protocol version rather than two copies of the same list.