On Tue, May 3, 2016 at 2:21 PM, David Turner <dtur...@twopensource.com> wrote:
> On Tue, 2016-05-03 at 01:33 -0400, Jeff King wrote:
>> 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.
>

I thought this is by design as upload-pack is a different program, i.e. it
could be developed out of sync with the client, adding/removing
capabilities there but not in fetch-pack. That doesn't make sense though.

We could introduce known_capabilities_v1 and _v2 respectively in shared
header files, though.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to