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

On Sat, 25 Jul 2026 at 17:25, Pablo Sabater <[email protected]> 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: <[email protected]>
>
> Github CI: https://github.com/pabloosabaterr/git/actions/runs/30155586279
>
> [1]: https://lore.kernel.org/git/[email protected]/
>
> Signed-off-by: Pablo Sabater <[email protected]>
> ---
> 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!