All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.