Re: [PATCH GSoC v4 0/9] cat-file: extend remote-object-info to support %(objecttype)

From: Jeff King <peff@peff.net>
Date: Aug 7, 2026, 23:19 UTC
Message-ID: <20260807231900.GA2293966@coredump.intra.peff.net>
In-Reply-To: <DKIADCID62IW.1MII8E3AYCI6F@gmail.com>

On Fri, Aug 07, 2026 at 02:30:55AM +0200, Pablo Sabater wrote:

Show 17 quoted lines

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

Hmm, I dunno. Making it optional just seems to introduce more complications. The value of a separate "remote" is that it makes things simpler (IMHO).

So maybe it is best to leave it as-is:

  remote-object-info <remote> <objs...>

and then let cat-file handle it under the hood as an optimization, leaving the transport intact between calls, in expectation of another possible request.

It does mean that the remote may sit "open" if no other call arrives. In practice that's probably not a big deal. In most cases we'd either make more requests or hang up the batch-command session soon after. And for stateless transports, the connection naturally times out (e.g., even a persistent HTTP connection will hang up after a few seconds). So it would only be things like git-over-ssh where we keep the ssh session open waiting for more commands. That seems OK to me.

> 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 think we can leave it in the state your series has it, and then later come back and do the caching optimization. If we're not changing the protocol, then those changes are invisible to the caller, so there's no rush.

-Peff