Re: [PATCH GSoC RFC v13 00/12] cat-file: add remote-object-info to batch-command

> Calvin Wan's (calvinwan@google.com) patch series [1] and [2] respectively.
>
> Sometimes it is beneficial to retrieve information about an object without
> having to download it completely. The server logic for retrieving size has
> already been implemented and merged in "a2ba162cda (object-info: support for
> retrieving object info, 2021-04-20)"[3]. This patch series implement the client
> option for it.
>
> Eric's series adds the `remote-object-info` command to
> `cat-file --batch-command`. This command allows the client to make an
> object-info command request to a server that supports protocol v2.
>
> If the server uses protocol v2 but does not support the object-info capability,
> `cat-file --batch-command` will die.
>
> If a user attempts to use `remote-object-info` with protocol v1,
> `cat-file --batch-command` will die.
>
> Currently, only the size (%(objectsize)) is supported end to end in this
> implementation. The type (%(objecttype)) is known by the client's allow-list
> and request path but is not supported on the server side nor the response
> parsing. A follow up series will add full end-to-end support for %(objecttype).
>
> The default format for remote-object-info is set to %(objectname) %(objectsize).
> Once %(objecttype) is supported, the default format will be unified accordingly.
>
> If the batch command format includes unsupported fields such as %(objecttype),
> %(objectsize:disk), or %(deltabase), the command will return empty strings for
> each unsupported field.
>
> This series completes Eric's work mainly with the refactor of the validation
> of the placeholder with an allow-list that filters what the client asks with
> what the server is capable of provide following Jeff King's idea [4].
>
> I have a question for the design:
>
> 1. If the format includes unsupported fields such as %(objecttype) or
>    %(deltabase) it currently returns an empty string for each unsupported
>    field, this follows what for-each-ref does with known but inapplicable
>    atoms. However future placeholders that will be implemented: %(rest),
>    %(objectmode) can return empty strings. How should we differentiate
>    "unsupported" vs "no data".
>    Eric proposed to use a placeholder like "???" [5].
>    Should a placeholder be used?

> 2. _tangent/not related with this series_
>    'a2ba162cda' is designed to only work with full OIDs, which is
>    inconsistent with local `info` that does support short OIDs and in
>    case of being ambiguous returns a list of what possibly the user meant.
>
>    Because V2 protocol is thought to be stateless supporting short OIDs
>    could become more inconsistent with other remote commands that do not
>    support short OIDs. Maybe a --pick-first option? That does accept
>    short oids and picks the first match.