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

Re: [PATCH GSoC v4 0/9] cat-file: extend remote-object-info to support %(objecttype)

From
Pablo Sabater <pabloosabaterr@gmail.com>
Date
Aug 7, 2026, 00:30 UTC
Message-ID
<DKIADCID62IW.1MII8E3AYCI6F@gmail.com>
In-Reply-To
<20260806171714.GA1632126@coredump.intra.peff.net>
On Thu Aug 6, 2026 at 7:17 PM CEST, Jeff King wrote:
Show 13 quoted lines
> On Tue, Aug 04, 2026 at 08:42:54PM +0200, Pablo Sabater wrote:
>
>> Patches 1-5 are preparatory. They don't change what the command does:
>> - [1/9] is a test cleanup.
>> - [2/9] fixes a possible bug in case of a malformed response.
>> - [3/9] and [4/9] refactor how the object data is stored and handled. The
>>   why about this refactor comes from [2].
>
> Thanks, I think these refactors in patches 3 and 4 make sense and
> address the issues raised in the earlier thread. I'd actually take patch
> 3 just a step further, as below (which you are welcome to put on top of
> your series, or work it into the middle, or even take as inspiration and
> rewrite as part of another patch).
Wow, thanks a lot for getting so involved, I think I'll place it as is.
Show 57 quoted lines
>
> -- >8 --
> Subject: transport: drop remote object-info fields from transport struct
>
> A remote object-info request needs three things: the transport for
> contacting the remote, the list of oids to request, and a place to store
> the output.
>
> Rather than take these as function parameters, we take only the
> transport object, and expect the caller to have placed the other two
> into special fields in the transport struct. But this doesn't make much
> sense. The set of oids and results are really only valid for one
> request. There is no reason the transport would need to hang on to them
> outside of the single function call.
>
> Even though we save a few lines passing the parameters around through
> the various vtable functions, the result is harder to understand (for
> example, who is responsible for cleaning up results, and when shoudl it
> happen?). It also opens up the possibility of a subtle bug. A caller is
> likely to point those fields to stack variables which could go out of
> scope, and the transport struct would be left holding invalid pointers.
>
> This is mostly harmless now, as we disconnect the transport immediately
> after the sole caller of transport_fetch_object_info(). But conceptually
> we could keep we could keep the transport open and make multiple fetch
> calls (and reuse the same connection to the helper, to a remote HTTP
> server, and so on).
>
> So let's pull these out of the struct and pass them as function
> parameters. It's a little more verbose, but I think more clearly
> illustrates the intent. I've also tweaked a few function signatures to
> mark the input oid array as const, since it is purely an input to the
> function.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> I do think the concept of reusing the transport will become useful
> later. We limit a single request to 10,000 objects, so it is quite
> conceivable a caller would want to make several. That can mostly come
> later on top, though I think the design of the remote-object-info
> command makes it awkward. Each invocation provides a remote by name,
> which is then resolved to a transport. But a given caller is likely
> going to provide the same remote over and over again.
>
> We probably could get away with just caching the last-used transport and
> reusing it when fed the same remote name again. But we could perhaps
> also change the protocol (which AFAICT is not yet in any released
> version, so still available for changes) to specify the two
> independently, like:
>
>    remote https://example.com/foo.git
>    remote-object-info objA objB objC...
>    remote-object-info objX objY objZ
>
> And then it is more clear that setting "remote" is stateful, and will be
> used for subsequent remote-* commands. But maybe that statefulness is
> something we don't want. I dunno.

Yeah, I think it is not in any released version yet as the ps/cat-file-remote-object-info (the one that precedes this series) landed in 'master' the first What's cooking of August [1].

Given that, I think that it could be a good idea to have both, if a user foresees that he's only going to make one 'remote-object-info' command he can write it as it is now:

  remote-object-info <remote> objA objB

But if a user foresees that he will have to make multiple ones, we can make what you suggested:

>    remote https://example.com/foo.git
>    remote-object-info objA objB objC...
>    remote-object-info objX objY objZ

We would have to make the remote optional, if there's no remote die(), etc. We would also have to tell apart a remote from an OID in the first argument, but full OIDs and remote URLs are not very similar so that should not be hard haha.

I do like the idea, but I see it more as a follow-up series after this one, as the topic of this series is type support. Also, I'm biased as I have little time before my deadline ends.

I'm happy to keep doing things and there are more things related to the object-info protocol that I'd like to keep working on after finishing GSoC.

Show 169 quoted lines
>
> Anyway, either way I think the cleanup below is worth doing in the short
> term.
>
>  builtin/cat-file.c   |  6 ++----
>  fetch-object-info.c  |  4 ++--
>  fetch-object-info.h  |  2 +-
>  transport-helper.c   |  7 +++++--
>  transport-internal.h |  4 +++-
>  transport.c          | 14 +++++++++-----
>  transport.h          |  7 +++----
>  7 files changed, 25 insertions(+), 19 deletions(-)
>
> diff --git a/builtin/cat-file.c b/builtin/cat-file.c
> index 950d9f237f..4f4d791821 100644
> --- a/builtin/cat-file.c
> +++ b/builtin/cat-file.c
> @@ -730,10 +730,8 @@ static int get_remote_info(int argc,
>  		goto cleanup;
>  	}
>
> -	gtransport->smart_options->object_info_oids = object_info_oids;
> -
> -	gtransport->smart_options->object_info_results = results;
> -	retval = transport_fetch_object_info(gtransport);
> +	retval = transport_fetch_object_info(gtransport, object_info_oids,
> +					     results);
>  cleanup:
>  	transport_disconnect(gtransport);
>  	return retval;
> diff --git a/fetch-object-info.c b/fetch-object-info.c
> index ad27b1e4ca..385462c707 100644
> --- a/fetch-object-info.c
> +++ b/fetch-object-info.c
> @@ -12,7 +12,7 @@
>  /* Sends object-info command and its arguments into the request buffer. */
>  static void send_object_info_request(const int fd_out,
>  				     const struct string_list *server_options,
> -				     struct oid_array *oids,
> +				     const struct oid_array *oids,
>  				     unsigned ask_size,
>  				     unsigned ask_type)
>  {
> @@ -54,7 +54,7 @@ static int parse_object_size(const char *s, size_t *res)
>
>  void fetch_object_info(enum protocol_version version,
>  		       const struct string_list *server_options,
> -		       struct oid_array *oids,
> +		       const struct oid_array *oids,
>  		       struct packet_reader *reader,
>  		       struct fetch_object_info_results *results,
>  		       int stateless_rpc,
> diff --git a/fetch-object-info.h b/fetch-object-info.h
> index 10b3641f7c..2fba96c6f7 100644
> --- a/fetch-object-info.h
> +++ b/fetch-object-info.h
> @@ -29,7 +29,7 @@ struct oid_array;
>   */
>  void fetch_object_info(enum protocol_version version,
>  		       const struct string_list *server_options,
> -		       struct oid_array *oids,
> +		       const struct oid_array *oids,
>  		       struct packet_reader *reader,
>  		       struct fetch_object_info_results *results,
>  		       int stateless_rpc,
> diff --git a/transport-helper.c b/transport-helper.c
> index f3cb8f8662..d5a064d386 100644
> --- a/transport-helper.c
> +++ b/transport-helper.c
> @@ -786,11 +786,14 @@ static int fetch_refs(struct transport *transport,
>  	return -1;
>  }
>
> -static int fetch_object_info_helper(struct transport *transport)
> +static int fetch_object_info_helper(struct transport *transport,
> +				    const struct oid_array *oids,
> +				    struct fetch_object_info_results *results)
>  {
>  	get_helper(transport);
>  	if (process_connect(transport, 0))
> -		return transport->vtable->fetch_object_info(transport);
> +		return transport->vtable->fetch_object_info(transport, oids,
> +							    results);
>
>  	die(_("object-info requires protocol v2"));
>  }
> diff --git a/transport-internal.h b/transport-internal.h
> index 60db0bedcd..e7ead5d785 100644
> --- a/transport-internal.h
> +++ b/transport-internal.h
> @@ -51,7 +51,9 @@ struct transport_vtable {
>  	 *
>  	 * Uses object-info capability of v2 protocol.
>  	 */
> -	int (*fetch_object_info)(struct transport *transport);
> +	int (*fetch_object_info)(struct transport *transport,
> +				 const struct oid_array *oids,
> +				 struct fetch_object_info_results *results);
>
>  	/**
>  	 * Push the objects and refs. Send the necessary objects, and
> diff --git a/transport.c b/transport.c
> index 35acdf71a2..25e2c14a7b 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -433,7 +433,9 @@ static int get_bundle_uri(struct transport *transport)
>  				     transport->bundles, stateless_rpc);
>  }
>
> -static int fetch_object_info_via_pack(struct transport *transport)
> +static int fetch_object_info_via_pack(struct transport *transport,
> +				      const struct oid_array *oids,
> +				      struct fetch_object_info_results *results)
>  {
>  	int ret = 0;
>  	struct git_transport_data *data = transport->data;
> @@ -450,9 +452,9 @@ static int fetch_object_info_via_pack(struct transport *transport)
>
>  	fetch_object_info(data->version,
>  			  transport->server_options,
> -			  transport->smart_options->object_info_oids,
> +			  oids,
>  			  &reader,
> -			  data->options.object_info_results,
> +			  results,
>  			  transport->stateless_rpc, data->fd[1]);
>
>  	close(data->fd[0]);
> @@ -465,11 +467,13 @@ static int fetch_object_info_via_pack(struct transport *transport)
>  	return ret;
>  }
>
> -int transport_fetch_object_info(struct transport *transport)
> +int transport_fetch_object_info(struct transport *transport,
> +				const struct oid_array *oids,
> +				struct fetch_object_info_results *results)
>  {
>  	if (!transport->vtable->fetch_object_info)
>  		die(_("remote does not support object-info"));
> -	return transport->vtable->fetch_object_info(transport);
> +	return transport->vtable->fetch_object_info(transport, oids, results);
>  }
>
>  static int fetch_refs_via_pack(struct transport *transport,
> diff --git a/transport.h b/transport.h
> index 6948b65db9..39193d0077 100644
> --- a/transport.h
> +++ b/transport.h
> @@ -57,9 +57,6 @@ struct git_transport_options {
>  	 * common commits to this oidset instead of fetching any packfiles.
>  	 */
>  	struct oidset *acked_commits;
> -
> -	struct oid_array *object_info_oids;
> -	struct fetch_object_info_results *object_info_results;
>  };
>
>  enum transport_family {
> @@ -317,7 +314,9 @@ int transport_fetch_refs(struct transport *transport, struct ref *refs);
>  /*
>   * Fetch the object info from remote
>   */
> -int transport_fetch_object_info(struct transport *transport);
> +int transport_fetch_object_info(struct transport *transport,
> +				const struct oid_array *oids,
> +				struct fetch_object_info_results *results);
>
>  /*
>   * If this flag is set, unlocking will avoid to call non-async-signal-safe
I see everything all right.
There's two typos on the patch's commit message:
- s/shoudl/should/
- a duplicated "we could keep"

I will fix them, so if you see anything changed in your patch it's just that. If I end up changing anything else, I'll let you know.

[1]: https://lore.kernel.org/git/xmqqldanxbq9.fsf@gitster.g/T/#t

Thanks, a lot, Pablo

Previous: Jeff KingNext: Jeff King
Message 84 of 112 in “cat-file: extend remote-object-info to support %(objecttype)”
  1. 0/5 cat-file: extend remote-object-info to support %(objecttype)Pablo Sabater, Jul 25, 2026
  2. 1/5 protocol-caps: add type support to object-infoPablo Sabater, Jul 25, 2026
  3. Chandra PratapJul 29, 2026
  4. Pablo SabaterJul 29, 2026
  5. Junio C HamanoJul 29, 2026
  6. Karthik NayakJul 29, 2026
  7. 2/5 fetch-object-info: parse type from server responsePablo Sabater, Jul 25, 2026
  8. Chandra PratapJul 29, 2026
  9. Pablo SabaterJul 29, 2026
  10. Chandra PratapJul 29, 2026
  11. Karthik NayakJul 29, 2026
  12. Karthik NayakJul 29, 2026
  13. 3/5 fetch-object-info: request all supported options dynamicallyPablo Sabater, Jul 25, 2026
  14. Chandra PratapJul 29, 2026
  15. Pablo SabaterJul 29, 2026
  16. 4/5 serve: advertise type capabilityPablo Sabater, Jul 25, 2026
  17. Chandra PratapJul 29, 2026
  18. Pablo SabaterJul 29, 2026
  19. 5/5 cat-file: unify default formatPablo Sabater, Jul 25, 2026
  20. Chandra PratapJul 29, 2026
  21. Pablo SabaterJul 29, 2026
  22. Chandra PratapJul 29, 2026
  23. Pablo SabaterJul 29, 2026
  24. 0/6 cat-file: extend remote-object-info to support %(objecttype)Pablo Sabater, Jul 31, 2026
  25. 1/6 fetch-object-info: request all supported options dynamicallyPablo Sabater, Jul 31, 2026
  26. Junio C HamanoJul 31, 2026
  27. 2/6 t5701: use the test_file_size() helperPablo Sabater, Jul 31, 2026
  28. Junio C HamanoAug 1, 2026
  29. Pablo SabaterAug 1, 2026
  30. 3/6 protocol-caps: add type support to object-infoPablo Sabater, Jul 31, 2026
  31. Junio C HamanoAug 1, 2026
  32. 4/6 fetch-object-info: parse type from server responsePablo Sabater, Jul 31, 2026
  33. Junio C HamanoAug 1, 2026
  34. Junio C HamanoAug 1, 2026
  35. Pablo SabaterAug 1, 2026
  36. Jeff KingAug 1, 2026
  37. Jeff KingAug 1, 2026
  38. Junio C HamanoAug 2, 2026
  39. Pablo SabaterAug 2, 2026
  40. Jeff KingAug 2, 2026
  41. Junio C HamanoAug 2, 2026
  42. Junio C HamanoAug 2, 2026
  43. Jeff KingAug 2, 2026
  44. Junio C HamanoAug 2, 2026
  45. Pablo SabaterAug 1, 2026
  46. 5/6 serve: advertise type capabilityPablo Sabater, Jul 31, 2026
  47. Chandra PratapAug 1, 2026
  48. Pablo SabaterAug 1, 2026
  49. 6/6 cat-file: unify default formatPablo Sabater, Jul 31, 2026
  50. 0/8 cat-file: extend remote-object-info to support %(objecttype)Pablo Sabater, Aug 3, 2026
  51. 1/8 t5701: use test_file_size() to get the size of a filePablo Sabater, Aug 3, 2026
  52. Junio C HamanoAug 3, 2026
  53. Pablo SabaterAug 3, 2026
  54. 2/8 fetch-object-info: detect truncated server responsesPablo Sabater, Aug 3, 2026
  55. Junio C HamanoAug 3, 2026
  56. Pablo SabaterAug 3, 2026
  57. 3/8 fetch-object-info: pass arguments directly instead of a structPablo Sabater, Aug 3, 2026
  58. Junio C HamanoAug 3, 2026
  59. Karthik NayakAug 4, 2026
  60. Pablo SabaterAug 4, 2026
  61. 4/8 fetch-object-info: use dedicated struct for the resultsPablo Sabater, Aug 3, 2026
  62. Junio C HamanoAug 3, 2026
  63. Pablo SabaterAug 3, 2026
  64. 5/8 protocol-caps: add type support to object-infoPablo Sabater, Aug 3, 2026
  65. 6/8 fetch-object-info: parse type from server responsePablo Sabater, Aug 3, 2026
  66. 7/8 serve: advertise type capabilityPablo Sabater, Aug 3, 2026
  67. 8/8 cat-file: unify default formatPablo Sabater, Aug 3, 2026
  68. 0/9 cat-file: extend remote-object-info to support %(objecttype)Pablo Sabater, Aug 4, 2026
  69. 1/9 t5701: use test_file_size() to get the size of a filePablo Sabater, Aug 4, 2026
  70. 2/9 fetch-object-info: detect malformed server responsesPablo Sabater, Aug 4, 2026
  71. Junio C HamanoAug 4, 2026
  72. 3/9 fetch-object-info: pass arguments directly instead of a structPablo Sabater, Aug 4, 2026
  73. Junio C HamanoAug 4, 2026
  74. Karthik NayakAug 6, 2026
  75. 5/9 fetch-object-info: die() on the remaining error pathPablo Sabater, Aug 4, 2026
  76. 4/9 fetch-object-info: use dedicated struct for the resultsPablo Sabater, Aug 4, 2026
  77. Junio C HamanoAug 4, 2026
  78. Pablo SabaterAug 4, 2026
  79. 6/9 protocol-caps: add type support to object-infoPablo Sabater, Aug 4, 2026
  80. 7/9 fetch-object-info: parse type from server responsePablo Sabater, Aug 4, 2026
  81. 8/9 serve: advertise type capabilityPablo Sabater, Aug 4, 2026
  82. 9/9 cat-file: unify default formatPablo Sabater, Aug 4, 2026
  83. Jeff KingAug 6, 2026
  84. Pablo SabaterAug 7, 2026
  85. Jeff KingAug 7, 2026
  86. 00/10 cat-file: extend remote-object-info to support %(objecttype)Pablo Sabater, Aug 7, 2026
  87. 01/10 t5701: use test_file_size() to get the size of a filePablo Sabater, Aug 7, 2026
  88. 02/10 fetch-object-info: detect malformed server responsesPablo Sabater, Aug 7, 2026
  89. 03/10 fetch-object-info: pass arguments directly instead of a structPablo Sabater, Aug 7, 2026
  90. 04/10 fetch-object-info: use dedicated struct for the resultsPablo Sabater, Aug 7, 2026
  91. 05/10 fetch-object-info: die() on the remaining error pathPablo Sabater, Aug 7, 2026
  92. 06/10 transport: drop remote object-info fields from transport structPablo Sabater, Aug 7, 2026
  93. 07/10 protocol-caps: add type support to object-infoPablo Sabater, Aug 7, 2026
  94. 08/10 fetch-object-info: parse type from server responsePablo Sabater, Aug 7, 2026
  95. 09/10 serve: advertise type capabilityPablo Sabater, Aug 7, 2026
  96. 10/10 cat-file: unify default formatPablo Sabater, Aug 7, 2026
  97. Pablo SabaterAug 7, 2026
  98. 00/10 cat-file: extend remote-object-info to support %(objecttype)Pablo Sabater, Aug 8, 2026
  99. 01/10 t5701: use test_file_size() to get the size of a filePablo Sabater, Aug 8, 2026
  100. 02/10 fetch-object-info: detect malformed server responsesPablo Sabater, Aug 8, 2026
  101. 03/10 fetch-object-info: pass arguments directly instead of a structPablo Sabater, Aug 8, 2026
  102. 04/10 fetch-object-info: use dedicated struct for the resultsPablo Sabater, Aug 8, 2026
  103. 05/10 fetch-object-info: die() on the remaining error pathPablo Sabater, Aug 8, 2026
  104. 06/10 transport: drop remote object-info fields from transport structPablo Sabater, Aug 8, 2026
  105. Junio C HamanoAug 8, 2026
  106. Chandra PratapAug 8, 2026
  107. Karthik NayakAug 11, 2026
  108. 07/10 protocol-caps: add type support to object-infoPablo Sabater, Aug 8, 2026
  109. 08/10 fetch-object-info: parse type from server responsePablo Sabater, Aug 8, 2026
  110. 09/10 serve: advertise type capabilityPablo Sabater, Aug 8, 2026
  111. 10/10 cat-file: unify default formatPablo Sabater, Aug 8, 2026
  112. Jeff KingAug 8, 2026

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.