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