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

On Sat, 25 Jul 2026 at 17:25, Pablo Sabater [off-list ref] wrote:

"%(objecttype)" is already known by the client's allow-list, but neither
the client nor the server knows how to handle type. This series continues
the work for git cat-file --batch-command extending remote-object-info
to support "%(objecttype)" end to end. It is based on its predecessor
series "cat-file: add remote-object-info to batch-command" [1].

Type is the last property that is identical on the server and on the
client once fetched.

Whether to support more metadata such as:

- objectsize:disk
- deltabase
- objectmode (needs context)

should be discussed, unlike size and type, the rest depend on how things
are packed on the server and on what the client already has, so they
cannot reliably match local once fetched. IMO they are not worth
supporting, I can't find a use case for them.

Makes sense to me. The metadata you listed depends on the local packfile
storage where the repository lives.

`objectmode` depends on the tree pointing to the blob, so it wouldn't be
accessible using the current infrastructure anyway.

Adding new placeholders has become trivial.
To add a new placeholder, follow the steps in this series and add it to
the client's allow-list at 'builtin/cat-file.c'.

Based-on: [ref]

Github CI: https://github.com/pabloosabaterr/git/actions/runs/30155586279

[1]: https://lore.kernel.org/git/20260724-ps-eric-work-rebase-v21-0-ba67f024fdff@gmail.com/ (local)

Signed-off-by: Pablo Sabater <redacted>
---
Pablo Sabater (5):
      protocol-caps: add type support to object-info
      fetch-object-info: parse type from server response
      fetch-object-info: request all supported options dynamically
      serve: advertise type capability
      cat-file: unify default format

The current incremental approach is safe and ensures every commit
compiles and passes tests. However, from a storytelling perspective for
the reviewers, I believe it's better to do any 'preparatory refactoring' before
starting the new feature.

Patch 3 (dynamically requesting supported options) doesn't actually depend
on type existing yet. I suggest bumping Patch 3 to be Patch 1 in V2.
That way, the client is already dynamic and ready, and the feature patches
can strictly focus on adding type:

- fetch-object-info: request all supported options dynamically (Current Patch 3)
- protocol-caps: add type support to object-info (Current Patch 1)
- fetch-object-info: parse type from server response (Current Patch 2)
- serve: advertise type capability (Current Patch 4)
- cat-file: unify default format (Current Patch 5)

 Documentation/git-cat-file.adoc        | 17 +++-----
 Documentation/gitprotocol-v2.adoc      | 15 +++++--
 builtin/cat-file.c                     |  7 ---
 fetch-object-info.c                    | 23 +++++++---
 protocol-caps.c                        | 21 +++++++--
 serve.c                                |  4 +-
 t/t1017-cat-file-remote-object-info.sh | 80 +++++++++++++---------------------
 t/t5701-git-serve.sh                   | 27 ++++++++++++
 8 files changed, 113 insertions(+), 81 deletions(-)

This series is definitely a lot smaller than I thought it would be. Looks like
most of the heavy lifting was already done with the previous series.

Good for us!