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

> On Sat, 25 Jul 2026 at 17:25, Pablo Sabater <pabloosabaterr@gmail.com> 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: <20260724-ps-eric-work-rebase-v21-0-ba67f024fdff@gmail.com>
>>
>> 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/
>>
>> Signed-off-by: Pablo Sabater <pabloosabaterr@gmail.com>
>> ---
>> 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.