Re: What's cooking in git.git (Jul 2026, #10)

["Pablo Sabater" <pabloosabaterr@gmail.com>]

On Fri Jul 24, 2026 at 2:33 AM CEST, Junio C Hamano wrote:
> "Pablo Sabater" <pabloosabaterr@gmail.com> writes:
>
>> On Thu Jul 23, 2026 at 4:38 AM CEST, Junio C Hamano wrote:
>>>
>>> * ps/cat-file-remote-object-info (2026-07-18) 13 commits
>>>  - cat-file: make remote-object-info allow-list adapt to the server
>>>  - cat-file: add remote-object-info to batch-command
>>>  - transport: add client support for object-info
>>>  - serve: advertise object-info feature
>>>  - protocol-caps: check object existence regardless of the attributes requested
>>>  - fetch-pack: move fetch initialization
>>>  - connect: make write_fetch_command_and_capabilities() more generic
>>>  - fetch-pack: move write_fetch_command_and_capabilities() to connect.c
>>>  - fetch-pack: use unsigned int for hash_algo variable
>>>  - fetch-pack: drop the static advertise_sid variable
>>>  - t1006: extract helper functions into new 'lib-cat-file.sh'
>>>  - cat-file: declare loop counter inside for()
>>>  - transport-helper: fix memory leak of helper on disconnect
>>>
>>>  The 'remote-object-info' command has been added to 'git cat-file
>>>  --batch-command', allowing clients to request object metadata
>>>  (currently size) from a remote server via protocol v2 without
>>>  downloading the entire object.  Format placeholders are dynamically
>>>  filtered on the client based on server-advertised capabilities,
>>>  returning empty strings for inapplicable or unsupported fields.
>>>
>>>  Needs review.
>>>  source: <20260718-ps-eric-work-rebase-v20-0-0c13962ac532@gmail.com>
>>>
>>
>> Hi,
>>
>> Karthik reviewed it a few days ago [1] and it looked good to him. Two tiny
>> nits came up, which don't seem worth a reroll on their own.
>>
>> I think the series is good unless further issues come up.
>>
>> [1]: https://lore.kernel.org/git/CAOLa=ZS8J4t12ab1=3-LRYNuZOwqSHG861iYm97JjF3mGprvJA@mail.gmail.com/
>
> I was silently hoping that you would fix these two nits, saying that
> one of the alone might not warrant reroll but if we have multiple,
> we would better get them right for the final version, or something
> ;-)

I'll fix them right now :)

Thanks