git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Stefan Beller <sbeller@google.com>
Date
May 4, 2016, 16:44 UTC
Message-ID
<CAGZ79kbi+g2EnZosyYpAMfj8rFFV45vtgyeEJR3Fe8LG+zut7Q@mail.gmail.com>
In-Reply-To
<1462310486.4123.81.camel@twopensource.com>
On Tue, May 3, 2016 at 2:21 PM, David Turner <dturner@twopensource.com> wrote:
Show 41 quoted lines
> 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.

Previous: David TurnerNext: Stefan Beller
Message 22 of 40 in “Protocol v2 patches”
  1. 00/14 Protocol v2 patchesStefan Beller, Apr 29, 2016
  2. 01/14 upload-pack: make client capability parsing code a separate functionStefan Beller, Apr 29, 2016
  3. 02/14 upload-pack.c: Refactor capability advertisingStefan Beller, Apr 29, 2016
  4. David TurnerApr 30, 2016
  5. Junio C HamanoMay 4, 2016
  6. 03/14 upload-pack-2: Implement the version 2 of upload-packStefan Beller, Apr 29, 2016
  7. David TurnerMay 2, 2016
  8. Stefan BellerMay 2, 2016
  9. David TurnerMay 2, 2016
  10. Duy NguyenMay 3, 2016
  11. Junio C HamanoMay 4, 2016
  12. 04/14 connect: rewrite feature parsing to work on string_listStefan Beller, Apr 29, 2016
  13. David TurnerMay 2, 2016
  14. Stefan BellerMay 2, 2016
  15. Junio C HamanoMay 4, 2016
  16. David TurnerMay 17, 2016
  17. 05/14 transport: add infrastructure to support a protocol version numberStefan Beller, Apr 29, 2016
  18. 06/14 remote.h: add get_remote_capabilities, request_capabilitiesStefan Beller, Apr 29, 2016
  19. David TurnerMay 2, 2016
  20. Jeff KingMay 3, 2016
  21. David TurnerMay 3, 2016
  22. Stefan BellerMay 4, 2016
  23. 07/14 fetch-pack: move capability selection out of do_fetch_packStefan Beller, Apr 29, 2016
  24. 08/14 fetch-pack: factor out get_selected_capabilities_listStefan Beller, Apr 29, 2016
  25. David TurnerMay 2, 2016
  26. 09/14 fetch-pack: Add negotiate_capabilitiesStefan Beller, Apr 29, 2016
  27. 10/14 do_fetch_pack: select capabilities for transport version 1 onlyStefan Beller, Apr 29, 2016
  28. 11/14 builtin/fetch-pack: add argument for transport versionStefan Beller, Apr 29, 2016
  29. 12/14 Add test for fetch-packStefan Beller, Apr 29, 2016
  30. David TurnerMay 2, 2016
  31. 13/14 WIP add test for git pullStefan Beller, Apr 29, 2016
  32. 14/14 WIP test git fetchStefan Beller, Apr 29, 2016
  33. David TurnerMay 2, 2016
  34. Stefan BellerMay 2, 2016
  35. David TurnerMay 24, 2016
  36. Duy NguyenMay 24, 2016
  37. David TurnerMay 25, 2016
  38. Junio C HamanoMay 25, 2016
  39. David TurnerMay 25, 2016
  40. Jeff KingMay 25, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.