On 3/9/2022 1:41 PM, Junio C Hamano wrote: > "Derrick Stolee via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > >> diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt >> index 72ab8139052..ac4c4352aae 100644 >> --- a/Documentation/git-bundle.txt >> +++ b/Documentation/git-bundle.txt >> @@ -75,8 +75,11 @@ verify <file>:: >> cleanly to the current repository. This includes checks on the >> bundle format itself as well as checking that the prerequisite >> commits exist and are fully linked in the current repository. >> - 'git bundle' prints a list of missing commits, if any, and exits >> - with a non-zero status. >> + Information about additional capabilities, such as "object filter", >> + is printed. See "Capabilities" in link:technical/bundle-format.html >> + for more information. Finally, 'git bundle' prints a list of >> + missing commits, if any. The exit code is zero for success, but >> + will be nonzero if the bundle file is invalid. > > Hmph. I wasn't expecting this change (not objecting, but mostly am > surprised) relative to the previous round where the filter was > mentioned only when we issue an error message. I was expecting to > see something like "list-filters <file>", which is analog to the > "list-heads <file>", to help those who want to programatically build > around the "git bundle" command output. Or "--list-capabilities" to > accomodate the current, this, and future capabilities. We already > have the object-format thing before this series. Do we have an > interface to expose that out of a given bundle file? The object format does _not_ appear to be output by 'git bundle verify'. I just ran t6020 under GIT_TEST_DEFAULT_HASH=sha256 and see the capability being written, but not output by verify: The bundle contains these 10 refs: d519553fbcf280df4448d588c25a51872f2d8dec95ba65a8a1bd3c64a5eec664 refs/heads/main 265b1effb3fdb80e04f7ea64e717f5677ddf57d00145dce7c508ba1f5ddb9081 refs/heads/release 611ac8182ea26d7aad227873b70f584593af1aa584bbdd37b36055e71be6ccd7 refs/heads/topic/1 4251af01ec70cdca692a3d15d78ccb9a6ca92ef344bd2dbc3bac20081347ae9b refs/heads/topic/2 611ac8182ea26d7aad227873b70f584593af1aa584bbdd37b36055e71be6ccd7 refs/pull/1/head ec7e40a591df46923b25fd44bd86a2a80927f343d141f55ddf295c5d2d57959e refs/pull/2/head 754e9363bbfce179d35ccc48ae3a3c81db95a489cc632fafe5c10b25aed29d74 refs/tags/v1 a96c78650835f2041c49dce964bb759add14cfc4d35af3b7ee2b22289f9ba817 refs/tags/v2 398a930e72d21ea455c982227cca3c8fb5feb88c31f1d42226a3e6c42ff8db8f refs/tags/v3 d519553fbcf280df4448d588c25a51872f2d8dec95ba65a8a1bd3c64a5eec664 HEAD The bundle uses this filter: blob:none The bundle records a complete history. partial.bdl is okay This output does not seem to be designed for machine parsing, so this extension of "The bundle uses this filter:" shouldn't be problematic. A similar addition for object-format should be possible as a follow-up. Further, it seems you are asking for something that just reads the header and supplies valuable data from the header such as the refs and the capabilities. Perhaps 'git bundle header <file>'? (We already have 'git bundle list-heads', so maybe we should leave the refs out of 'git bundle header' output?) I can add both as follow-ups to my existing list of things. Thanks, -Stolee
