Re: [PATCH GSoC v2 4/6] fetch-object-info: parse type from server response

On Sat, Aug 01, 2026 at 07:14:37PM -0400, Jeff King wrote:

> Yes, this conditional loading is exactly how we use the pointers. I
> agree that a bool would be smaller, though I doubt it really matters in
> practice. You shouldn't have a large number of object_info structs. You
> should have one that you use over and over. And it does not point to a
> heap allocation, but usually to a stack variable in the caller.
> 
> I don't think you'd need type_valid (at least not as the object_info
> code is written now). If you ask for it, then either the query is
> satisfied, or we return an error.
> 
> I think the pointer system goes all the way back to 9a49059022
> (sha1_object_info_extended(): expose a bit more info, 2011-05-12). It is
> mostly just mirroring the pointers that would be passed directly to the
> function (but marshalling them in a struct so callers don't have to pass
> a zillion NULLs). So:
> 
>   read_object_info(oid, &size);
> 
> became:
> 
>   struct object_info query;
>   query.sizep = &size;
>   read_object_info(oid, &query);

OK, I tried to read through the patches here, not having looked at the
topic previously. I think it doesn't make sent to use object_info here.
It is about collecting the options to make the query for _one_ object,
so it expects you to point to where it should write the results.

But what you want is to query N objects and get all of the results back.
You _could_ do that with N object_info queries, one per object, like
this:

   enum object_type types;
   struct object_info queries;

   ALLOC_ARRAY(types, nr);
   CALLOC_ARRAY(queries, nr);

   for (size_t i = 0; i < nr; i++)
	queries[i].typep = &types[i];

   /* you can imagine this is calling read_object_info() in a loop
    * under the hood */
   do_many_queries(&oids, nr, &queries);

   /* now we have our answers */
   for (size_t i = 0; i < nr; i++)
	do_something(oids[i], types[i]);

But it's kind of silly. Every query is the same, and you'd rather just
pass _one_ query struct that says what you're interested in. But since
you are not calling read_object_info() yourself here, why use its query
struct? You can make your own using boolean flags or whatever.

And I guess that's what started this conversation. The fundamental
difference is asking about one object (and using pointers to tell where
to put the answer) versus asking about N.

-Peff