安装 Big Sur 后，不能再通过 HTTPS git clone large repos答案

【问题标题】：Can no longer git clone large repos via HTTPS since installing Big Sur安装 Big Sur 后，不能再通过 HTTPS git clone large repos
【发布时间】：2021-06-02 02:11:24
【问题描述】：

每当我尝试克隆大型存储库时，都会发生这种情况：

$ git clone https://github.com/yarnpkg/berry.git
Cloning into 'berry'...
remote: Enumerating objects: 60762, done.
remote: Counting objects: 100% (1155/1155), done.
remote: Compressing objects: 100% (588/588), done.
Receiving objects:   5% (3454/60762), 13.86 MiB | 4.60 MiB/ (etc etc)
fatal: fetch-pack: invalid index-pack output

我没有安装防病毒软件，也没有使用 VPN。我尝试连接到另一个网络并没有解决它，所以 Big Sur 一定是有什么东西导致了这个问题。我不确定还能尝试什么。

macOS 11.4，APFS+ 文件系统，git 2.31.1

我已经尝试过更改压缩设置，弄乱包大小设置，this post 也没有帮助。我发布这个是因为我已经尝试了迄今为止在 Internet 上看到的所有其他内容，但没有任何效果。

【问题讨论】：

您能否更具体地了解您正在使用的操作系统、文件系统、git 版本？
这能回答你的问题吗？ fatal: early EOF fatal: index-pack failed
@OznOg 我不这么认为。该问题的答案基本上是“较旧版本的 Git 的问题”和“内存不足”。那里没有解释为什么升级操作系统版本会导致它。
您是否尝试停用帖子中发现的内容？还有那个stackoverflow.com/questions/21277806/… ?
@matt “所以你是说任何拥有 Big Sur 的人都会经历这种情况？”不，Big Sur 改变了一些在某些设置中破坏了 Git 但在其他设置中没有破坏的东西，这是完全合理的。类似的错误一直在发生。

标签： git macos-big-sur

【解决方案1】：

这应该是一个评论（因为它不是一个答案），但我需要一些格式和一个很多的空间。简短的版本是您需要找出git index-pack 行为不端或失败的原因。（通过智能协议获取通常会检索一个所谓的 thin 包，git fetch 需要使用git index-pack --fix-thin 来“增肥”。）

如果git index-pack 的输出与git fetch-pack 的预期不匹配，则会出现“无效的索引包输出”错误。 Here's the code involved:

char *index_pack_lockfile(int ip_out, int *is_well_formed)
{
    char packname[GIT_MAX_HEXSZ + 6];
    const int len = the_hash_algo->hexsz + 6;

    /*
     * The first thing we expect from index-pack's output
     * is "pack\t%40s\n" or "keep\t%40s\n" (46 bytes) where
     * %40s is the newly created pack SHA1 name.  In the "keep"
     * case, we need it to remove the corresponding .keep file
     * later on.  If we don't get that then tough luck with it.
     */
    if (read_in_full(ip_out, packname, len) == len && packname[len-1] == '\n') {
        const char *name;

        if (is_well_formed)
            *is_well_formed = 1;
        packname[len-1] = 0;
        if (skip_prefix(packname, "keep\t", &name))
            return xstrfmt("%s/pack/pack-%s.keep",
                       get_object_directory(), name);
        return NULL;
    }
    if (is_well_formed)
        *is_well_formed = 0;
    return NULL;
}

这是从fetch-pack.c 的get_pack function 运行的，它运行git index-pack 的参数基于大量变量。如果你运行 git clone 并将环境变量 GIT_TRACE 设置为 1，你可以观察到 Git 运行 git index-pack。此处对index_pack_lockfile 的调用仅在设置do_keep 时发生，它最初基于args->keep_pack，但如果包头的hdr_entries 值等于或超过unpack_limit（请参见第859 行附近），则可以设置。

您可以使用fetch.unpackLimit 和/或transfer.unpackLimit 控制unpack_limit 的值。默认值为 100。您也许可以使用这些来解决 index-pack 的一些问题，也许——但 index-pack 不应该以任何方式失败。请注意，如果您想强制 git fetch 使用 git unpack-objects，还必须禁用对象检查 (fsck_objects)。

在git fetch 检索的数据上直接运行git index-pack 可能会很有趣。（考虑安装一个 shell 脚本来代替普通的 git index-pack，该脚本会打印其参数，然后在其自己的进程组上使用 kill -STOP，以便您可以检查临时文件。）

【讨论】：

【解决方案2】：

解决了！

TL;DR：ulimit 限制了我的文件系统上的最大文件大小。为什么这在 Catalina 从来不是问题，谁知道呢。

我的 shell 启动脚本中有这个：

ulimit -n 65536 65536

第二个参数是错误的。它将最大文件大小限制为 32MB。奇怪的是，我在 Catalina 上有完全相同的设置，并且没有任何限制。一定有人提供了这个设置，我只是复制了它，没有理解其中的含义。

我跑了ulimit -n unlimited unlimited，现在一切都很好！

关于 ulimit 从 Catalina 到 Big Sur 变化的有趣笔记：

我在我的 Catalina 安装上运行了这个：

$ ulimit -a                                                   
-t: cpu time (seconds)              unlimited
-f: file size (blocks)              65536
-d: data seg size (kbytes)          unlimited
-s: stack size (kbytes)             8192
-c: core file size (blocks)         0
-v: address space (kbytes)          unlimited
-l: locked-in-memory size (kbytes)  unlimited
-u: processes                       11136
-n: file descriptors                65536
$ mkfile 500m whoa                                             
$

看那个！创建 500MB 文件没问题，明显忽略了 ulimit 的 65536 块文件大小限制。

但在 Big Sur 上，使用相同的 ulimit 设置：

$ mkfile 500m whoa                                                                                                                               
[1]    22267 file size limit exceeded  mkfile 500m whoa

【讨论】：