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

Re: [PATCH v2 2/3] promisor-remote: allow a server to advertise more fields

From
Christian Couder <christian.couder@gmail.com>
Date
May 19, 2025, 14:11 UTC
Message-ID
<CAP8UFD31PfhJY3jQpBmvbAB6eh43GFfsKzcXby7LshX76Qjekw@mail.gmail.com>
In-Reply-To
<CAOLa=ZSwzvfQ8MupFzuMEpHCKJRY8p06m-FfyE-deqOsgK_feg@mail.gmail.com>
On Wed, May 7, 2025 at 2:45 PM Karthik Nayak <karthik.188@gmail.com> wrote:
Show 32 quoted lines
>
> Christian Couder <christian.couder@gmail.com> writes:
>
> [snip]
>
> > diff --git a/Documentation/gitprotocol-v2.adoc b/Documentation/gitprotocol-v2.adoc
> > index 5598c93e67..b4648a7ce6 100644
> > --- a/Documentation/gitprotocol-v2.adoc
> > +++ b/Documentation/gitprotocol-v2.adoc
> > @@ -785,33 +785,52 @@ retrieving the header from a bundle at the indicated URI, and thus
> >  save themselves and the server(s) the request(s) needed to inspect the
> >  headers of that bundle or bundles.
> >
> > -promisor-remote=<pr-infos>
> > +promisor-remote=<pr-info>
> >  ~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> >  The server may advertise some promisor remotes it is using or knows
> >  about to a client which may want to use them as its promisor remotes,
> > -instead of this repository. In this case <pr-infos> should be of the
> > +instead of this repository. In this case <pr-info> should be of the
> >  form:
> >
> > -     pr-infos = pr-info | pr-infos ";" pr-info
> > +     pr-info = pr-fields | pr-info ";" pr-info
> >
> > -     pr-info = "name=" pr-name | "name=" pr-name "," "url=" pr-url
> > +     pr-fields = fld-name "=" fld-value | pr-fields "," pr-fields
> >
>
> From this, it seems like the order of the fields shouldn't matter, but
> this is not the case.

I would prefer to keep the simpler version as I find these grammar notations not very easy to understand.

In v3 there is:

=> The "name" and "url" fields MUST appear first in each pr-fields, in that order.

And I think it's enough, especially since the parsing is relaxed so it will work if they are not in this order.

Show 6 quoted lines
> wouldn't it be better to say:
>
>   pr-infos = pr-info | pr-infos ";" pr-info
>
>   pr-info = "name=" pr-name | "name=" pr-name "," "url=" pr-url
>   pr-info = pr-info | pr-info "," fld-name "=" fld-value

Could this be interpreted to mean that it is Ok to have "name=" pr-name "," "url=" pr-url several times in a single pr-info?

This seems to me really more complex than needed, and I think it's better to keep the simple version and then clarify things with the above sentence.

Show 39 quoted lines
> [snip]
>
> > diff --git a/promisor-remote.c b/promisor-remote.c
> > index 24d0e70132..70abec4c24 100644
> > --- a/promisor-remote.c
> > +++ b/promisor-remote.c
> > @@ -314,6 +314,84 @@ static int allow_unsanitized(char ch)
> >       return ch > 32 && ch < 127;
> >  }
> >
> > +/*
> > + * List of field names allowed to be used in the "promisor-remote"
> > + * protocol capability. Each field should correspond to a configurable
> > + * property of a remote that can be relevant for the client.
> > + */
> > +static const char *allowed_fields[] = {
> > +     "partialCloneFilter", /* Filter used for partial clone */
> > +     "token",              /* Authentication token for the remote */
> > +     NULL
> > +};
> > +
> > +/*
> > + * Check if 'field' is in the list of allowed field names for the
> > + * "promisor-remote" protocol capability.
> > + */
> > +static int is_allowed_field(const char *field)
> > +{
> > +     const char **p;
> > +
> > +     for (p = allowed_fields; *p; p++)
> > +             if (!strcasecmp(*p, field))
> > +                     return 1;
> > +     return 0;
> > +}
> > +
> > +static int valid_field(struct string_list_item *item, void *cb_data)
> > +{
>
> Nit: Shouldn't this be `is_valid_field` similar to `is_allowed_field`?
Yeah, I have renamed it `is_valid_field`
Show 6 quoted lines
> > +     const char *field = item->string;
> > +     const char *config_key = (const char *)cb_data;
> > +
> > +     if (!is_allowed_field(field)) {
>
> Nit: Can't we just inline this?

We could, but I think the is_allowed_field() makes sense on its own too, while the current one is very specific to be used in filter_string_list(). So I prefer keeping is_allowed_field() separate.

Show 30 quoted lines
> > +             warning(_("unsupported field '%s' in '%s' config"), field, config_key);
> > +             return 0;
> > +     }
> > +     return 1;
> > +}
> > +
> > +static char *fields_from_config(struct string_list *fields_list, const char *config_key)
> > +{
> > +     char *fields = NULL;
> > +
> > +     if (!git_config_get_string(config_key, &fields) && *fields) {
> > +             string_list_split_in_place(fields_list, fields, ", ", -1);
> > +             filter_string_list(fields_list, 0, valid_field, (void *)config_key);
> > +     }
> > +
> > +     return fields;
> > +}
> > +
> > +static struct string_list *fields_sent(void)
> > +{
> > +     static struct string_list fields_list = STRING_LIST_INIT_NODUP;
> > +     static int initialized = 0;
> > +
> > +     if (!initialized) {
> > +             fields_list.cmp = strcasecmp;
> > +             fields_from_config(&fields_list, "promisor.sendFields");
>
> Nit: Here too, can't this be inlined? While the modularity is nice, I'm
> not sure the redirection is warranted for such small functions with very
> specific usecases.

In a follow up patch in this series we reuse fields_from_config() so I think it's better to keep it separate.

> [snip]
>
> Apart from the nits, the patch looks good :)
Thanks for the review!
Previous: Karthik NayakNext: Christian Couder
Message 25 of 107 in “Make the "promisor-remote" capability support extra fields”
  1. 0/4 Make the "promisor-remote" capability support extra fieldsChristian Couder, Apr 14, 2025
  2. 1/4 config: move is_config_key_char() to "config.h"Christian Couder, Apr 14, 2025
  3. 2/4 promisor-remote: refactor to get rid of 'struct strvec'Christian Couder, Apr 14, 2025
  4. Patrick SteinhardtApr 22, 2025
  5. Christian CouderApr 29, 2025
  6. 3/4 promisor-remote: allow a server to advertise extra fieldsChristian Couder, Apr 14, 2025
  7. Junio C HamanoApr 14, 2025
  8. Patrick SteinhardtApr 22, 2025
  9. Christian CouderApr 29, 2025
  10. Christian CouderApr 29, 2025
  11. 4/4 promisor-remote: allow a client to check extra fieldsChristian Couder, Apr 14, 2025
  12. 0/3 Make the "promisor-remote" capability support more fieldsChristian Couder, Apr 29, 2025
  13. 1/3 promisor-remote: refactor to get rid of 'struct strvec'Christian Couder, Apr 29, 2025
  14. Patrick SteinhardtMay 7, 2025
  15. Christian CouderMay 19, 2025
  16. Karthik NayakMay 7, 2025
  17. Christian CouderMay 19, 2025
  18. 2/3 promisor-remote: allow a server to advertise more fieldsChristian Couder, Apr 29, 2025
  19. Patrick SteinhardtMay 7, 2025
  20. Christian CouderMay 19, 2025
  21. Patrick SteinhardtMay 27, 2025
  22. Junio C HamanoMay 27, 2025
  23. Christian CouderJun 11, 2025
  24. Karthik NayakMay 7, 2025
  25. Christian CouderMay 19, 2025
  26. 3/3 promisor-remote: allow a client to check fieldsChristian Couder, Apr 29, 2025
  27. Patrick SteinhardtMay 7, 2025
  28. Christian CouderMay 19, 2025
  29. Christian CouderMay 2, 2025
  30. 0/5 Make the "promisor-remote" capability support more fieldsChristian Couder, May 19, 2025
  31. 1/5 promisor-remote: refactor to get rid of 'struct strvec'Christian Couder, May 19, 2025
  32. Karthik NayakMay 20, 2025
  33. Christian CouderMay 20, 2025
  34. Junio C HamanoMay 20, 2025
  35. Christian CouderMay 21, 2025
  36. Junio C HamanoMay 21, 2025
  37. Christian CouderJun 11, 2025
  38. 2/5 promisor-remote: allow a server to advertise more fieldsChristian Couder, May 19, 2025
  39. Justin ToblerMay 21, 2025
  40. Christian CouderJun 11, 2025
  41. Patrick SteinhardtMay 27, 2025
  42. Christian CouderJun 11, 2025
  43. 3/5 promisor-remote: refactor how we parse advertised fieldsChristian Couder, May 19, 2025
  44. 4/5 promisor-remote: allow a client to check fieldsChristian Couder, May 19, 2025
  45. 5/5 promisor-remote: use string constants for 'name' and 'url' tooChristian Couder, May 19, 2025
  46. 0/5 Make the "promisor-remote" capability support more fieldsChristian Couder, Jun 11, 2025
  47. 1/5 promisor-remote: refactor to get rid of 'struct strvec'Christian Couder, Jun 11, 2025
  48. Karthik NayakJun 19, 2025
  49. Christian CouderJun 25, 2025
  50. Justin ToblerJun 23, 2025
  51. Christian CouderJun 25, 2025
  52. 2/5 promisor-remote: allow a server to advertise more fieldsChristian Couder, Jun 11, 2025
  53. Karthik NayakJun 19, 2025
  54. Christian CouderJun 25, 2025
  55. Justin ToblerJun 23, 2025
  56. Christian CouderJun 25, 2025
  57. 3/5 promisor-remote: refactor how we parse advertised fieldsChristian Couder, Jun 11, 2025
  58. 4/5 promisor-remote: allow a client to check fieldsChristian Couder, Jun 11, 2025
  59. 5/5 promisor-remote: use string constants for 'name' and 'url' tooChristian Couder, Jun 11, 2025
  60. Karthik NayakJun 19, 2025
  61. 0/5 Make the "promisor-remote" capability support more fieldsChristian Couder, Jun 25, 2025
  62. 1/5 promisor-remote: refactor to get rid of 'struct strvec'Christian Couder, Jun 25, 2025
  63. Junio C HamanoJun 25, 2025
  64. Christian CouderJul 21, 2025
  65. 3/5 promisor-remote: refactor how we parse advertised fieldsChristian Couder, Jun 25, 2025
  66. 2/5 promisor-remote: allow a server to advertise more fieldsChristian Couder, Jun 25, 2025
  67. Junio C HamanoJun 25, 2025
  68. Christian CouderJul 21, 2025
  69. Junio C HamanoJul 21, 2025
  70. Christian CouderJul 31, 2025
  71. Jean-Noël AvilaJun 27, 2025
  72. Christian CouderJul 21, 2025
  73. 4/5 promisor-remote: allow a client to check fieldsChristian Couder, Jun 25, 2025
  74. 5/5 promisor-remote: use string constants for 'name' and 'url' tooChristian Couder, Jun 25, 2025
  75. Junio C HamanoJul 7, 2025
  76. Christian CouderJul 8, 2025
  77. 0/5 Make the "promisor-remote" capability support more fieldsChristian Couder, Jul 21, 2025
  78. 1/5 promisor-remote: refactor to get rid of 'struct strvec'Christian Couder, Jul 21, 2025
  79. 2/5 promisor-remote: allow a server to advertise more fieldsChristian Couder, Jul 21, 2025
  80. 3/5 promisor-remote: refactor how we parse advertised fieldsChristian Couder, Jul 21, 2025
  81. Junio C HamanoJul 21, 2025
  82. Christian CouderJul 31, 2025
  83. 4/5 promisor-remote: allow a client to check fieldsChristian Couder, Jul 21, 2025
  84. Junio C HamanoJul 21, 2025
  85. Christian CouderJul 31, 2025
  86. 5/5 promisor-remote: use string constants for 'name' and 'url' tooChristian Couder, Jul 21, 2025
  87. Junio C HamanoJul 21, 2025
  88. 0/5 Make the "promisor-remote" capability support more fieldsChristian Couder, Jul 31, 2025
  89. 1/5 promisor-remote: refactor to get rid of 'struct strvec'Christian Couder, Jul 31, 2025
  90. 2/5 promisor-remote: allow a server to advertise more fieldsChristian Couder, Jul 31, 2025
  91. 3/5 promisor-remote: refactor how we parse advertised fieldsChristian Couder, Jul 31, 2025
  92. Junio C HamanoJul 31, 2025
  93. Christian CouderSep 8, 2025
  94. 4/5 promisor-remote: allow a client to check fieldsChristian Couder, Jul 31, 2025
  95. 5/5 promisor-remote: use string constants for 'name' and 'url' tooChristian Couder, Jul 31, 2025
  96. Junio C HamanoJul 31, 2025
  97. Junio C HamanoAug 28, 2025
  98. Christian CouderSep 8, 2025
  99. 0/7 Make the "promisor-remote" capability support more fieldsChristian Couder, Sep 8, 2025
  100. 1/7 promisor-remote: refactor to get rid of 'struct strvec'Christian Couder, Sep 8, 2025
  101. 2/7 promisor-remote: allow a server to advertise more fieldsChristian Couder, Sep 8, 2025
  102. 3/7 promisor-remote: use string constants for 'name' and 'url' tooChristian Couder, Sep 8, 2025
  103. 4/7 promisor-remote: refactor how we parse advertised fieldsChristian Couder, Sep 8, 2025
  104. 5/7 promisor-remote: use string_list_split() in filter_promisor_remote()Christian Couder, Sep 8, 2025
  105. 6/7 promisor-remote: allow a client to check fieldsChristian Couder, Sep 8, 2025
  106. 7/7 promisor-remote: use string_list_split() in mark_remotes_as_accepted()Christian Couder, Sep 8, 2025
  107. Junio C HamanoSep 8, 2025

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.