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

Re: [PATCH v4 1/4] transport-helper: no connection restriction in connect_helper

From
Jiang Xin <worldhello.net@gmail.com>
Date
Jan 16, 2024, 09:04 UTC
Message-ID
<CANYiYbFOa-E8Pivhgn_nmy982fn7VPtb803bewnC_UV7qY3xcw@mail.gmail.com>
In-Reply-To
<owlyy1cvhua5.fsf@fine.c.googlers.com>
On Fri, Jan 12, 2024 at 3:42 PM Linus Arver <linusa@google.com> wrote:
Show 36 quoted lines
>
> Jiang Xin <worldhello.net@gmail.com> writes:
>
> > From: Jiang Xin <zhiyou.jx@alibaba-inc.com>
> >
> > When commit b236752a (Support remote archive from all smart transports,
> > 2009-12-09) added "remote archive" support for "smart transports", it
> > was for transport that supports the ".connect" method. The
> > "connect_helper()" function protected itself from getting called for a
> > transport without the method before calling process_connect_service(),
>
> OK.
>
> > which did not work with such a transport.
>
> How about 'which only worked with the ".connect" method.' ?
>
> >
> > Later, commit edc9caf7 (transport-helper: introduce stateless-connect,
> > 2018-03-15) added a way for a transport without the ".connect" method
> > to establish a "stateless" connection in protocol-v2, which
>
> s/which/where
>
> > process_connect_service() was taught to handle the "stateless"
> > connection,
>
> I think using 'the ".stateless_connect" method' is more consistent with
> the rest of this text.
>
> > making the old safety valve in its caller that insisted
> > that ".connect" method must be defined too strict, and forgot to loosen
> > it.
>
> I think just "...making the old protection too strict. But edc9caf7
> forgot to adjust this protection accordingly." is simpler to read.
Thanks for the above suggestions, and will update in next reroll.
Show 30 quoted lines
> > Remove the restriction in the "connect_helper()" function and give the
> > function "process_connect_service()" the opportunity to establish a
> > connection using ".connect" or ".stateless_connect" for protocol v2. So
> > we can connect with a stateless-rpc and do something useful. E.g., in a
> > later commit, implements remote archive for a repository over HTTP
> > protocol.
> >
> > Helped-by: Junio C Hamano <gitster@pobox.com>
> > Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
> > ---
> >  transport-helper.c | 2 --
> >  1 file changed, 2 deletions(-)
> >
> > diff --git a/transport-helper.c b/transport-helper.c
> > index 49811ef176..2e127d24a5 100644
> > --- a/transport-helper.c
> > +++ b/transport-helper.c
> > @@ -662,8 +662,6 @@ static int connect_helper(struct transport *transport, const char *name,
> >
> >       /* Get_helper so connect is inited. */
> >       get_helper(transport);
> > -     if (!data->connect)
> > -             die(_("operation not supported by protocol"));
>
> Should we still terminate early here if both data->connect and
> data->stateless_connect are not truthy? It would save a few CPU cycles,
> but even better, remain true to the the original intent of the code.
> Maybe there was a really good reason to terminate early here that we're
> not aware of?
>

It's not necessary to check data->connect here, because it will terminate if fail to connect by calling the function "process_connect_service()".

> But also, what about the case where both are enabled? Should we print an
> error message? (Maybe this concern is outside the scope of this series?)

In the function "process_connect_service()", we can see that "connect" has a higher priority than "stateless-connect".

>
> >       if (!process_connect_service(transport, name, exec))
> >               die(_("can't connect to subservice %s"), name);

Regardless of whether "connect" or "stateless-connect" is used, the function process_connect_service() will return 1 if the connection is successful. If the connection fails, it will terminate here.

Previous: Junio C HamanoNext: Linus Arver
Message 23 of 61 in “transport-helper: no connection restriction in connect_helper”
  1. 1/2 transport-helper: no connection restriction in connect_helperJiang Xin, Sep 19, 2023
  2. 2/2 archive: support remote archive from stateless transportJiang Xin, Sep 19, 2023
  3. Junio C HamanoSep 19, 2023
  4. Jiang XinSep 20, 2023
  5. 0/3 support remote archive from stateless transportJiang Xin, Sep 23, 2023
  6. Junio C HamanoSep 25, 2023
  7. Jiang XinSep 26, 2023
  8. 1/3 transport-helper: no connection restriction in connect_helperJiang Xin, Sep 23, 2023
  9. Junio C HamanoSep 25, 2023
  10. 2/3 transport-helper: run do_take_over in connect_helperJiang Xin, Sep 23, 2023
  11. Junio C HamanoSep 25, 2023
  12. Jiang XinOct 4, 2023
  13. 0/4 support remote archive from stateless transportJiang Xin, Oct 4, 2023
  14. 1/4 transport-helper: no connection restriction in connect_helperJiang Xin, Oct 4, 2023
  15. 3/4 transport-helper: call do_take_over() in connect_helperJiang Xin, Oct 4, 2023
  16. 4/4 archive: support remote archive from stateless transportJiang Xin, Oct 4, 2023
  17. 2/4 transport-helper: call do_take_over() in process_connectJiang Xin, Oct 4, 2023
  18. Junio C HamanoOct 4, 2023
  19. 0/4 support remote archive via stateless transportJiang Xin, Dec 14, 2023
  20. 1/4 transport-helper: no connection restriction in connect_helperJiang Xin, Dec 14, 2023
  21. Linus ArverJan 12, 2024
  22. Junio C HamanoJan 12, 2024
  23. Jiang XinJan 16, 2024
  24. Linus ArverJan 18, 2024
  25. Jiang XinJan 19, 2024
  26. Linus ArverJan 20, 2024
  27. 2/4 transport-helper: call do_take_over() in process_connectJiang Xin, Dec 14, 2023
  28. 3/4 transport-helper: call do_take_over() in connect_helperJiang Xin, Dec 14, 2023
  29. Linus ArverJan 12, 2024
  30. Jiang XinJan 16, 2024
  31. 4/4 archive: support remote archive from stateless transportJiang Xin, Dec 14, 2023
  32. Linus ArverJan 12, 2024
  33. 0/6 support remote archive via stateless transportJiang Xin, Jan 16, 2024
  34. 1/6 transport-helper: no connection restriction in connect_helperJiang Xin, Jan 16, 2024
  35. Linus ArverJan 20, 2024
  36. 2/6 remote-curl: supports git-upload-archive serviceJiang Xin, Jan 16, 2024
  37. Linus ArverJan 20, 2024
  38. 3/6 transport-helper: protocol-v2 supports upload-archiveJiang Xin, Jan 16, 2024
  39. 4/6 http-backend: new rpc-service for git-upload-archiveJiang Xin, Jan 16, 2024
  40. 5/6 transport-helper: call do_take_over() in connect_helperJiang Xin, Jan 16, 2024
  41. Linus ArverJan 20, 2024
  42. 6/6 transport-helper: call do_take_over() in process_connectJiang Xin, Jan 16, 2024
  43. Linus ArverJan 20, 2024
  44. Jiang XinJan 21, 2024
  45. 0/6 support remote archive via stateless transportJiang Xin, Jan 21, 2024
  46. 1/6 transport-helper: no connection restriction in connect_helperJiang Xin, Jan 21, 2024
  47. 2/6 remote-curl: supports git-upload-archive serviceJiang Xin, Jan 21, 2024
  48. 3/6 transport-helper: protocol v2 supports upload-archiveJiang Xin, Jan 21, 2024
  49. 4/6 http-backend: new rpc-service for git-upload-archiveJiang Xin, Jan 21, 2024
  50. 5/6 transport-helper: call do_take_over() in connect_helperJiang Xin, Jan 21, 2024
  51. 6/6 transport-helper: call do_take_over() in process_connectJiang Xin, Jan 21, 2024
  52. Linus ArverJan 21, 2024
  53. Junio C HamanoJan 22, 2024
  54. 3/3 archive: support remote archive from stateless transportJiang Xin, Sep 23, 2023
  55. Eric SunshineSep 24, 2023
  56. Jiang XinSep 24, 2023
  57. rsbecker@nexbridge.comSep 24, 2023
  58. Jiang XinSep 25, 2023
  59. rsbecker@nexbridge.comSep 25, 2023
  60. Phillip WoodSep 24, 2023
  61. Jiang XinSep 24, 2023

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.