从消息中，我可以假设它试图获取当前的存储库，但没有。
如果您的bundle是满的，而不是增量的，那么您可以尝试初始化一个空的存储库，然后从它运行命令。
如果是增量验证，则可能应在具有较早历史记录的存储库中运行验证

如果使用git init创建一个空的git repo并启动verify，现在它可以工作了。
这很奇怪，因为它很容易显示一个好的错误消息，而不是崩溃。
这是非常正确的，而Git 2.22.1（Q2 2019）正在做的是：
参见Johannes Schindelin ( dscho )（2019年5月27日）。
（由Junio C Hamano -- gitster --合并至commit abbd504，2019年7月25日）

bundle verify：如果在没有对象数据库的情况下调用，则出错

捆绑包的处理方式是：它们真的是很薄的包，上面只有很少的糖。所以当被要求验证一个包时，我们真的需要一个存储库（或者更恰当地说，一个对象数据库）来工作。
如果调用git bundle verify时没有使用这样的对象数据库，我们将使用一条有用的错误消息来排 debugging 误。
康斯坦丁·里亚比采夫报道。
这意味着git/gitbundle.c#verify_bundle()函数现在包括：

if (!r || !r->objects || !r->objects->odb)
    return error(_("need a repository to verify a bundle"));

在Git 2.34（Q4 2021）中，"薄包"部分得到了澄清：
参见commit 1d9c8da、commit 0bb92f3、commit 9ab80dd、commit 5c8273d（2021年7月31日），作者为Ævar Arnfjörð Bjarmason ( avar )。
（由Junio C Hamano -- gitster --合并至commit f19b275，2021年8月24日）

bundle doc：重写"描述"部分

签署人：埃瓦尔·阿恩菲约德·比亚尔马森
重写"git bundle"（man）的"DESCRIPTION"部分，从一般意义上讨论bundle是什么开始，而不是直接讨论它们可能用于什么的一个示例。
这会更改文档，而自从2e0afaf中添加了该命令（"Add git-bundle：通过归档移动对象和引用"，2007年2月22日，Git v1.5.1-rc1--merge）。
有一个discussion about whether to say anything at all about "thin packs" here。
我认为，对于那些好奇的读者来说，愿意阅读技术文档是很好的，但让我们明确地说，没有"厚包"，差异不应该是问题。
git bundle现在在其手册页中包括：
创建、解压缩和操作"bundle"文件。bundle用于"离线"传输Git对象，而无需在网络连接的另一端设置活动的"服务器"。
它们可以用于创建存储库的增量备份和完全备份，并将一个存储库中的引用状态中继到另一个存储库。
通过ssh://和https://等协议获取或"读取"的Git命令也可以操作bundle文件。可以使用git clone从bundle中获取新的仓库，使用git fetch从仓库中获取仓库，并使用git ls-remote列出仓库中包含的引用。没有相应的"写入"支持。即不支持"git推送"到包中。
有关如何使用包的示例，请参见下面的"示例"部分。

捆绑包格式

bundle是.pack文件（请参见git pack-objects），文件头指示bundle中包含哪些引用。
与压缩归档格式本身一样，bundle可以是自包含的，也可以使用排除来创建。
使用修订排除创建的捆绑包是使用--thin选项到git pack-objects创建的"精简包"，并使用--fix-thin选项到git index-pack解捆绑。
在使用版本排除项时，没有创建"厚包"的选项，用户不应该担心差异。通过使用"瘦包"，使用排除项创建的捆绑包的大小更小。在此指出它们的"瘦"只是出于好奇，并作为对其他文档的参考
有关更多详细信息，请参见technical/bundle-format（bundle-format文档）以及technical/pack-format（包格式文档）中对"thin pack"的讨论。
随着Git 2.40（2023年第一季度）的发布，git bundle <subcmd>将更具弹性。
参见Ævar Arnfjörð Bjarmason ( avar )的commit 6d5e9e5、commit e778ecb（2022年12月27日）和commit 891cb09（2022年12月20日）。
（由Junio C Hamano -- gitster --合并至commit bc58ebf，2023年1月5日）

bundle：不要在"git bundle"上分段

报告人：于贝尔·亚苏多维茨
签署人：埃瓦尔·阿恩菲约德·比亚尔马森
检验人：休伯特·亚苏多维茨
由于aef7d75（"builtin/bundle.c：让parse-options解析子命令"，2022年8月19日，Git v2.38.0-rc0--merge列在batch #17中）如果没有提供参数，我们就已经分段了。
修复很容易，因为所有的"git bundle"（man）子命令都需要一个非选项参数，我们可以检查调用parse-options（）后是否还有参数。
这将利用添加到73c3253中的代码（"bundle：bundle文件之前的选项框架"，2019 - 11 - 10，Git v2.25.0-rc0--merge列于batch #2中），在此变更之前，该代码始终无法访问。
在73c3253中，我们永远不会到达它，因为我们已经在cmd_bundle()本身中检查了"argc < 2"。
然后当aef7d75（我们在此修复其segfault）将此代码迁移到子命令API时，它删除了"argc < 2"检查，但我们仍然在parse_options_cmd_bundle()中检查错误的"argc"，我们需要检查"newargc"。
"argc"将始终为>= 1，因为它必须至少包含子命令名称本身（例如"create"）。
顺便说一句，这可以被安全地压缩到这里面，但是对于这个最小的segfault修复，我们不要这样做，因为它是一个不相关的重构：

--- a/builtin/bundle.c
+++ b/builtin/bundle.c
@@ -55,13 +55,12 @@ static int parse_options_cmd_bundle(int argc,
      const char * const usagestr[],
      const struct option options[],
      char **bundle_file) {
- int newargc;
- newargc = parse_options(argc, argv, NULL, options, usagestr,
+ argc = parse_options(argc, argv, NULL, options, usagestr,
               PARSE_OPT_STOP_AT_NON_OPTION);
- if (!newargc)
+ if (!argc)
      usage_with_options(usagestr, options);
  *bundle_file = prefix_filename(prefix, argv[0]);
- return newargc;
+ return argc;
 }

static int cmd_bundle_create(int argc, const char **argv, const char *prefix) {