[GSoC] Re: [PATCH v11 8/8] cat-file: add remote-object-info to batch-command

From: Pablo Sabater <pabloosabaterr@gmail.com>
Date: Mar 12, 2026, 21:41 UTC
Message-ID: <20260312214154.89120-1-pabloosabaterr@gmail.com>
In-Reply-To: <20250324033922.GB690093@coredump.intra.peff.net>

From: Pablo Sabater Jiménez <pabloosabaterr@gmail.com>

Jeff King <peff@peff.net> wrote:

Show 6 quoted lines

> In similar situations for the ref-filter printer, I think we use the
> empty string for unsupported cases. E.g.:
> 
>   git for-each-ref --format='%(refname) %(tagger)'
> 
> will show the empty string for %(tagger) of non-tags.

while playing with Eric's v11 for my proposal I tested some of the mentioned cases.

I tested this, and for-each-ref dies on unknown atoms:

  $ git for-each-ref --format='%(test)'
  fatal: unknown field name: test

So the empty string behavior is just for known atoms but not applicable to a given ref type, like %(tagger) on a non-tag. For remote-object-info, the atoms are known to expand_atom() but the remote can't provide data for them, returning an empty string would be the closest match.

Show 7 quoted lines

> No, I meant that --batch-command takes a single format string, but you
> can issue both local and remote requests to it. So for example:
> 
>   git cat-file --batch-command='%(objectname) %(objecttype) %(objectsize)' <<\EOF
>   info 683c54c999c301c2cd6f715c411407c413b1d84e
>   remote-object-info c9d3534de317f31915f37e9d9c0d52d4cf901482
>   EOF

While testing Eric's v11 on this case, I found a bug beyond the segfault: when a local info query runs before remote-object-info in the same session, data->type retains stale data from the local query, and remote-object-info silently returns the wrong type.

To reproduce, query a commit locally then a blob remotely:

  git cat-file --batch-command='%(objectname) %(objectsize) %(objecttype)' <<-EOF
  info <commit-oid>
  remote-object-info origin <blob-oid>
  EOF

example for my test case:
  git cat-file --batch-command='%(objectname) %(objectsize) %(objecttype)' <<EOF
  info fede5cd8e8da0ee5d984753286c77f80339ec832
  remote-object-info file:///home/blopa/tests/CPU16-remote.git 9a455a4325cc0b0ba839f2414395257511ab6213
  EOF
  fede5cd8e8da0ee5d984753286c77f80339ec832 237 commit
  9a455a4325cc0b0ba839f2414395257511ab6213 256 commit

  git cat-file -t 9a455a4325cc0b0ba839f2414395257511ab6213
  blob

The blob is being reported as "commit" because data->type isnt being cleared between commands. The size is correct (provided by the server) but the type is wrong.

This is even worse because user wouldn't even receive any signal that there is an error.

To reproduce it, this is what I did: Server repo needs `transfer.advertiseobjectinfo true`, and both client and server must run Eric's v11, I used file://.

In the meantime I'll keep testing Eric's v11 and report any issues I find.

Pablo