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

On Tue, May 3, 2016 at 2:21 PM, David Turner [off-list ref] wrote:

On Tue, 2016-05-03 at 01:33 -0400, Jeff King wrote:

quoted

On Mon, May 02, 2016 at 02:57:43PM -0400, David Turner wrote:

quoted

On Fri, 2016-04-29 at 16:34 -0700, Stefan Beller wrote:

quoted

+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.