由于pack-object失败，git fetch失败

Question

当我将我们的远程仓库添加为上游并尝试获取时，它会失败，并出现以下错误提示：

    $ git fetch upstream
    remote: Counting objects: 11901, done.
    remote: aborting due to possible repository corruption on the remote side.
    error: pack-objects died of signal 9
    error: git upload-pack: git-pack-objects died with error.
    fatal: git upload-pack: aborting due to possible repository corruption on the re
    mote side.
    fatal: protocol error: bad pack header

我知道这个失败是由于仓库中有巨大的文件（我们确实有），但为什么当我克隆同一个仓库时它不会失败呢？因为我能够成功地克隆该仓库。难道在克隆请求时不应该打包相同的对象吗？

- nikel

Answer 1

稍微解释一下 VonC的回答 ...

首先，值得注意的是，信号9 指的是 SIGKILL 并且往往是发生在远程主机是Linux主机的情况下，由于Linux "OOM killer" 而导致进程被终止（尽管有些非Linux系统也会类似行为）。

接下来，让我们谈谈对象和包文件。Git“对象”是在git仓库中找到的四种类型的项目之一:“blob”（一个文件）;“tree”（一组blob，它们的模式和它们的名称-作为存储在目录中的内容:i.e.，当提交解包时将成为目录或文件夹）;“commit”（其中包括提交作者、消息和顶级树等数据）;以及“tag”（已注释的标记）。对象可以存储为“loose objects”，每个对象都是单独的文件;但是这些可能占用大量的磁盘空间，因此它们可以被“packed”，将许多对象压缩到一个文件中。

从许多松散的对象制作打包文件并进行压缩是（或者至少可以是）一项cpu和内存密集型操作。所需的内存量取决于对象的数量及其底层大小：大文件需要更多的内存。许多大文件需要大量的内存。

接下来，正如VonC所指出的那样，git clone跳过了尝试使用“thin”包（通常情况下）。这意味着服务器只会传送它已经拥有的包文件。这是一种“节省内存”的操作：文件已经存在，服务器只需要传递它们。

另一方面，git fetch会尽可能避免发送客户端已经拥有的大量数据。使用“聪明”的协议，客户端和服务器进行一种对话，你可以把它看作是以下内容：

“我有A对象，需要B和C；你有B和C吗？我还有D、E和F。”

“我有B但我需要C，我有D和E；请给我发送A、C和F。”

因此，服务器从原始包中提取“感兴趣”/“想要”的对象，然后尝试将它们压缩成一个新的（但“薄”的）包。这意味着服务器将调用git-pack-objects。

如果服务器内存不足（"不足"是相对于 git-pack-objects 需要的数量而言），它很可能会调用 "OOM killer"。由于 git-pack-objects 占用大量内存，该进程很可能成为 "OOM killer" 杀死的对象。然后，在客户端上，您会看到有关 git-pack-objects 因 signal 9 (SIGKILL) 而死亡的消息。

（当然，服务器的 OOM killer 可能会杀死其他完全不同的东西，比如错误数据库服务器。 :-)）

- torek

---

详细而富有指导性，一如既往。+1 - VonC

Answer 2

这取决于协议，但是Documentation/technical/pack-heuristics.txt指出克隆和提取之间的第一个区别。

在另一个方向上，fetch、git-fetch-pack和git-clone-pack会通过ssh或与守护进程通信在另一端调用git-upload-pack。有两种情况：使用-k的clone-pack和fetch-pack将保留未扩展的下载包文件，因此我们不使用thin pack传输；否则，生成的pack将具有delta，但没有同一pack中的基对象。但是，如果upload-pack支持，没有-k的fetch-pack将把接收到的pack分解为各个单独的对象，因此我们会自动要求upload-pack给我们提供一个thin pack。

因此，在协议方面，Documentation/technical/pack-protocol.txt说明了一个fetch可以返回比git clone更多的数据。

- VonC