Re: [PATCH GSoC v4 4/9] fetch-object-info: use dedicated struct for the results

Junio C Hamano <[email protected]> Tue, 04 Aug 2026 13:58:17 -0700
Newsgroups org.kernel.vger.git
Message-ID <[email protected]>
Pablo Sabater <[email protected]> writes:

>  builtin/cat-file.c  | 59 +++++++++-----------------------------
>  fetch-object-info.c | 81 ++++++++++++++++++++++++++---------------------------
>  fetch-object-info.h | 27 +++++++++++++-----
>  object-file.c       | 10 -------
>  odb.h               |  3 --
>  transport.c         |  3 +-
>  transport.h         |  5 ++--
>  7 files changed, 77 insertions(+), 111 deletions(-)

We lost ~30 lines mostly thanks to losing an intermediate structure
and need to flip pointer members in it to point at heap allocated
locations?

> -struct protocol_placeholder_entry {
> -	const char *option;
> -	const char *atom;
> -};
> -
> -static const struct protocol_placeholder_entry remote_atom_map[] = {
> -	{"size", "objectsize"},
> -	{"type", "objecttype"},
> -	/*
> -	 * Add new protocol options here. Even if the server doesn't support
> -	 * them the allow_list will drop them if the server doesn't advertise
> -	 * them.
> -	 */
> -};

Hmph, it would not make any difference in the final result, as we
are losing protocol_placeholder_entry and this list of atoms, but
I am somewhat confused.   Why we already had "type" here, even
though we are adding support for it much later in the series (and
unlike the previous iteration, this iteration did not do the
ask/want_type thing in the previous step)?