Re: [PATCH 06/14] remote.h: add get_remote_capabilities, request_capabilities

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]