Re: [PATCH GSoC 0/5] cat-file: extend remote-object-info to support %(objecttype)
- From
- Chandra Pratap <chandrapratap3519@gmail.com>
- Date
- Jul 29, 2026, 09:52 UTC
- Message-ID
- <CA+J6zkSvwqy4QdL16oQ_W=Noi81i-dLtAdAQqU3u9A1mQV3izQ@mail.gmail.com>
- In-Reply-To
- <20260725-objecttype-support-v1-0-2d4ca3bbabf1@gmail.com>
On Sat, 25 Jul 2026 at 17:25, Pablo Sabater <pabloosabaterr@gmail.com> wrote:
Show 20 quoted lines
> > "%(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.
Show 18 quoted lines
> 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)
Show 9 quoted lines
> 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!