为什么 Git 在 blob 文件中存储（和散列）blob 大小？

Question

Git 的 blob 对象文件格式为 blob <size string>\0<data>。 识别 Blob 的 SHA-1 哈希不是单独根据 Blob 内容计算的，而是根据标头增强的 Blob 数据计算的（如上所述）。

作为一个纯粹主义者，我不喜欢那种架构。它将数据的通用属性（其 SHA1 哈希）与一些特定于 git 的标头混合在一起。

纯数据 blob 存储的另一个优点是可以使用“写时复制”将文件添加到索引中，而不是复制整个文件。所需空间可以减半，一些操作可以变得更快。

那么，为什么 Git 开发人员选择使用基于标头的格式而不是纯数据格式呢？

附： AFAIK 在 Git 的早期阶段，SHA-1 哈希是基于压缩数据的。

Answer 1

在 Git 早期的 AFAIK 中，SHA-1 哈希是基于压缩数据的。

是的，这会导致各种“优化”，例如commit 65c2e0c, git 0.99, June 2015：

在不膨胀所有内容的情况下查找 SHA1 对象的大小。

但“How does git compute file hashes?”所示的新格式可以追溯到：

• git diff，在commit 051308f (git 1.4.0-rc1, May 2006)
• git fast-import，始于commit db5e523 (git 1.5.0, Aug. 2006)

每次都需要数据的长度来对数据本身做任何事情。