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

Re: [PATCH 04/14] connect: rewrite feature parsing to work on string_list

From
David Turner <dturner@twopensource.com>
Date
May 17, 2016, 22:23 UTC
Message-ID
<1463523829.24478.78.camel@twopensource.com>
In-Reply-To
<xmqqr3dhfuo9.fsf@gitster.mtv.corp.google.com>
On Wed, 2016-05-04 at 13:13 -0700, Junio C Hamano wrote:
Show 29 quoted lines
> Stefan Beller <sbeller@google.com> writes:
> 
> > Later on when we introduce the version 2 transport protocol, the
> > capabilities will not be transported in one lone string but each
> 
> s/lone/long/, I think.
> 
> > capability will be carried in its own pkt line.
> > 
> > To reuse existing infrastructure we would either need to join the
> > capabilities into a single string again later or refactor the
> > current
> > capability parsing to be using a data structure which fits both
> > versions of the transport protocol. We chose to implement the
> > later.
> > 
> > Signed-off-by: Stefan Beller <sbeller@google.com>
> > ---
> >  builtin/receive-pack.c | 15 ++++++---
> >  connect.c              | 82 +++++++++++++++++++++++---------------
> > ------------
> >  connect.h              |  2 +-
> >  upload-pack.c          | 13 ++++++--
> >  4 files changed, 58 insertions(+), 54 deletions(-)
> 
> I am not sure if the churn is make a right tradeoff here.
> 
> A loop to concatenate each segment into a strbuf before passing it
> to parse_feature_request would be at most 5 lines long, no?

I started looking at this again briefly today, and I actually think that string manipulation of this sort is a mistake. String manipulation is error-prone, and having an interface defined in terms of strings makes it hard for a reader to see what sorts of input are valid and invalid. (It's also often somewhat less efficient). So I think it is a good idea to improve the interface while we're already changing code in this area.

Previous: Junio C HamanoNext: Stefan Beller
Message 16 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.