Git development
 help / color / mirror / Atom feed
From: "Pablo Sabater" <pabloosabaterr@gmail.com>
To: "Jeff King" <peff@peff.net>, "Pablo Sabater" <pabloosabaterr@gmail.com>
Cc: <git@vger.kernel.org>, <chandrapratap3519@gmail.com>,
	<karthik.188@gmail.com>, <gitster@pobox.com>
Subject: Re: [PATCH GSoC v4 0/9] cat-file: extend remote-object-info to support %(objecttype)
Date: Fri, 07 Aug 2026 02:30:55 +0200	[thread overview]
Message-ID: <DKIADCID62IW.1MII8E3AYCI6F@gmail.com> (raw)
In-Reply-To: <20260806171714.GA1632126@coredump.intra.peff.net>

On Thu Aug 6, 2026 at 7:17 PM CEST, Jeff King wrote:
> 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.

>
> -- >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.

>
> 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


  reply	other threads:[~2026-08-07  0:30 UTC|newest]

Thread overview: 111+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-25 11:55 [PATCH GSoC 0/5] cat-file: extend remote-object-info to support %(objecttype) Pablo Sabater
2026-07-25 11:55 ` [PATCH GSoC 1/5] protocol-caps: add type support to object-info Pablo Sabater
2026-07-29  9:53   ` Chandra Pratap
2026-07-29 11:18     ` Pablo Sabater
2026-07-29 15:40     ` Junio C Hamano
2026-07-29 22:39   ` Karthik Nayak
2026-07-25 11:55 ` [PATCH GSoC 2/5] fetch-object-info: parse type from server response Pablo Sabater
2026-07-29  9:57   ` Chandra Pratap
2026-07-29 12:05     ` Pablo Sabater
2026-07-29 17:06       ` Chandra Pratap
2026-07-29 22:47   ` Karthik Nayak
2026-07-29 22:53     ` Karthik Nayak
2026-07-25 11:55 ` [PATCH GSoC 3/5] fetch-object-info: request all supported options dynamically Pablo Sabater
2026-07-29  9:57   ` Chandra Pratap
2026-07-29 12:07     ` Pablo Sabater
2026-07-25 11:55 ` [PATCH GSoC 4/5] serve: advertise type capability Pablo Sabater
2026-07-29  9:58   ` Chandra Pratap
2026-07-29 12:15     ` Pablo Sabater
2026-07-25 11:55 ` [PATCH GSoC 5/5] cat-file: unify default format Pablo Sabater
2026-07-29  9:59   ` Chandra Pratap
2026-07-29 12:23     ` Pablo Sabater
2026-07-29  9:52 ` [PATCH GSoC 0/5] cat-file: extend remote-object-info to support %(objecttype) Chandra Pratap
2026-07-29 12:34   ` Pablo Sabater
2026-07-31 19:49 ` [PATCH GSoC v2 0/6] " Pablo Sabater
2026-07-31 19:49   ` [PATCH GSoC v2 1/6] fetch-object-info: request all supported options dynamically Pablo Sabater
2026-07-31 23:16     ` Junio C Hamano
2026-07-31 19:49   ` [PATCH GSoC v2 2/6] t5701: use the test_file_size() helper Pablo Sabater
2026-08-01  4:27     ` Junio C Hamano
2026-08-01 20:49       ` Pablo Sabater
2026-07-31 19:49   ` [PATCH GSoC v2 3/6] protocol-caps: add type support to object-info Pablo Sabater
2026-08-01  4:55     ` Junio C Hamano
2026-07-31 19:49   ` [PATCH GSoC v2 4/6] fetch-object-info: parse type from server response Pablo Sabater
2026-08-01  5:04     ` Junio C Hamano
2026-08-01 13:38       ` Junio C Hamano
2026-08-01 22:20         ` Pablo Sabater
2026-08-01 23:14           ` Jeff King
2026-08-01 23:29             ` Jeff King
2026-08-02  2:02               ` Junio C Hamano
2026-08-02 12:33                 ` Pablo Sabater
2026-08-02 15:43                   ` Jeff King
2026-08-02 16:35                     ` Junio C Hamano
2026-08-02 16:24                   ` Junio C Hamano
2026-08-02 16:38                     ` Jeff King
2026-08-02 22:24                       ` Junio C Hamano
2026-08-01 21:28       ` Pablo Sabater
2026-07-31 19:49   ` [PATCH GSoC v2 5/6] serve: advertise type capability Pablo Sabater
2026-08-01 12:12     ` Chandra Pratap
2026-08-01 21:30       ` Pablo Sabater
2026-07-31 19:49   ` [PATCH GSoC v2 6/6] cat-file: unify default format Pablo Sabater
2026-08-03 14:39 ` [PATCH GSoC v3 0/8] cat-file: extend remote-object-info to support %(objecttype) Pablo Sabater
2026-08-03 14:39   ` [PATCH GSoC v3 1/8] t5701: use test_file_size() to get the size of a file Pablo Sabater
2026-08-03 17:21     ` Junio C Hamano
2026-08-03 21:12       ` Pablo Sabater
2026-08-03 14:39   ` [PATCH GSoC v3 2/8] fetch-object-info: detect truncated server responses Pablo Sabater
2026-08-03 18:18     ` Junio C Hamano
2026-08-03 21:30       ` Pablo Sabater
2026-08-03 14:39   ` [PATCH GSoC v3 3/8] fetch-object-info: pass arguments directly instead of a struct Pablo Sabater
2026-08-03 18:23     ` Junio C Hamano
2026-08-04 15:23     ` Karthik Nayak
2026-08-04 15:34       ` Pablo Sabater
2026-08-03 14:39   ` [PATCH GSoC v3 4/8] fetch-object-info: use dedicated struct for the results Pablo Sabater
2026-08-03 18:28     ` Junio C Hamano
2026-08-03 21:46       ` Pablo Sabater
2026-08-03 14:39   ` [PATCH GSoC v3 5/8] protocol-caps: add type support to object-info Pablo Sabater
2026-08-03 14:39   ` [PATCH GSoC v3 6/8] fetch-object-info: parse type from server response Pablo Sabater
2026-08-03 14:39   ` [PATCH GSoC v3 7/8] serve: advertise type capability Pablo Sabater
2026-08-03 14:39   ` [PATCH GSoC v3 8/8] cat-file: unify default format Pablo Sabater
2026-08-04 18:42 ` [PATCH GSoC v4 0/9] cat-file: extend remote-object-info to support %(objecttype) Pablo Sabater
2026-08-04 18:42   ` [PATCH GSoC v4 1/9] t5701: use test_file_size() to get the size of a file Pablo Sabater
2026-08-04 18:42   ` [PATCH GSoC v4 2/9] fetch-object-info: detect malformed server responses Pablo Sabater
2026-08-04 20:40     ` Junio C Hamano
2026-08-04 18:42   ` [PATCH GSoC v4 3/9] fetch-object-info: pass arguments directly instead of a struct Pablo Sabater
2026-08-04 20:44     ` Junio C Hamano
2026-08-06 11:21     ` Karthik Nayak
2026-08-04 18:42   ` [PATCH GSoC v4 4/9] fetch-object-info: use dedicated struct for the results Pablo Sabater
2026-08-04 20:58     ` Junio C Hamano
2026-08-04 21:42       ` Pablo Sabater
2026-08-04 18:42   ` [PATCH GSoC v4 5/9] fetch-object-info: die() on the remaining error path Pablo Sabater
2026-08-04 18:43   ` [PATCH GSoC v4 6/9] protocol-caps: add type support to object-info Pablo Sabater
2026-08-04 18:43   ` [PATCH GSoC v4 7/9] fetch-object-info: parse type from server response Pablo Sabater
2026-08-04 18:43   ` [PATCH GSoC v4 8/9] serve: advertise type capability Pablo Sabater
2026-08-04 18:43   ` [PATCH GSoC v4 9/9] cat-file: unify default format Pablo Sabater
2026-08-06 17:17   ` [PATCH GSoC v4 0/9] cat-file: extend remote-object-info to support %(objecttype) Jeff King
2026-08-07  0:30     ` Pablo Sabater [this message]
2026-08-07 23:19       ` Jeff King
2026-08-07 22:06 ` [PATCH GSoC v5 00/10] " Pablo Sabater
2026-08-07 22:06   ` [PATCH GSoC v5 01/10] t5701: use test_file_size() to get the size of a file Pablo Sabater
2026-08-07 22:06   ` [PATCH GSoC v5 02/10] fetch-object-info: detect malformed server responses Pablo Sabater
2026-08-07 22:06   ` [PATCH GSoC v5 03/10] fetch-object-info: pass arguments directly instead of a struct Pablo Sabater
2026-08-07 22:06   ` [PATCH GSoC v5 04/10] fetch-object-info: use dedicated struct for the results Pablo Sabater
2026-08-07 22:07   ` [PATCH GSoC v5 05/10] fetch-object-info: die() on the remaining error path Pablo Sabater
2026-08-07 22:07   ` [PATCH GSoC v5 06/10] transport: drop remote object-info fields from transport struct Pablo Sabater
2026-08-07 22:07   ` [PATCH GSoC v5 07/10] protocol-caps: add type support to object-info Pablo Sabater
2026-08-07 22:07   ` [PATCH GSoC v5 08/10] fetch-object-info: parse type from server response Pablo Sabater
2026-08-07 22:07   ` [PATCH GSoC v5 09/10] serve: advertise type capability Pablo Sabater
2026-08-07 22:07   ` [PATCH GSoC v5 10/10] cat-file: unify default format Pablo Sabater
2026-08-07 23:12   ` [PATCH GSoC v5 00/10] cat-file: extend remote-object-info to support %(objecttype) Pablo Sabater
2026-08-08  0:02 ` [PATCH GSoC v6 " Pablo Sabater
2026-08-08  0:02   ` [PATCH GSoC v6 01/10] t5701: use test_file_size() to get the size of a file Pablo Sabater
2026-08-08  0:02   ` [PATCH GSoC v6 02/10] fetch-object-info: detect malformed server responses Pablo Sabater
2026-08-08  0:02   ` [PATCH GSoC v6 03/10] fetch-object-info: pass arguments directly instead of a struct Pablo Sabater
2026-08-08  0:02   ` [PATCH GSoC v6 04/10] fetch-object-info: use dedicated struct for the results Pablo Sabater
2026-08-08  0:02   ` [PATCH GSoC v6 05/10] fetch-object-info: die() on the remaining error path Pablo Sabater
2026-08-08  0:02   ` [PATCH GSoC v6 06/10] transport: drop remote object-info fields from transport struct Pablo Sabater
2026-08-08 16:21     ` Junio C Hamano
2026-08-08 18:59       ` Chandra Pratap
2026-08-08  0:02   ` [PATCH GSoC v6 07/10] protocol-caps: add type support to object-info Pablo Sabater
2026-08-08  0:02   ` [PATCH GSoC v6 08/10] fetch-object-info: parse type from server response Pablo Sabater
2026-08-08  0:02   ` [PATCH GSoC v6 09/10] serve: advertise type capability Pablo Sabater
2026-08-08  0:02   ` [PATCH GSoC v6 10/10] cat-file: unify default format Pablo Sabater
2026-08-08  7:41   ` [PATCH GSoC v6 00/10] cat-file: extend remote-object-info to support %(objecttype) Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DKIADCID62IW.1MII8E3AYCI6F@gmail.com \
    --to=pabloosabaterr@gmail.com \
    --cc=chandrapratap3519@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=karthik.188@gmail.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox