Re: What's cooking in git.git (Jul 2026, #10)
"Pablo Sabater" <[email protected]>
| Newsgroups | org.kernel.vger.git |
|---|---|
| Message-ID | <[email protected]> |
On Fri Jul 24, 2026 at 2:33 AM CEST, Junio C Hamano wrote: > "Pablo Sabater" <[email protected]> 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: <[email protected]> >>> >> >> 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