Git 和 SHA-256

Question

当前版本的 git (2.30.0) 是否已经默认使用 SHA256 来计算提交哈希？如果没有，如何为新的 git 存储库启用 SHA-256，以及如何检查某个 git 存储库是否使用 SHA-256 或 SHA-1 作为其提交哈希？

Answer 1

在最新版本的 Git 中，是使用 SHA-1 还是 SHA-256 是每个存储库的设置。该计划最终使将数据存储在 SHA-256 存储库中并使用 SHA-1 名称或 SHA-256 名称访问对象成为可能。SHA-1 仍然是默认值。

请注意，SHA-256 模式是实验性的，理论上可以改变，但没有计划这样做。Git 开发人员正在尽一切努力不破坏与现有 SHA-256 存储库的兼容性。

要创建具有SHA-256一个新的存储库，使用--object-format选项git init。如果您想知道本地存储库使用哪种算法，请运行git rev-parse --show-object-format，它将输出sha1或sha256。要查看远程存储库的哈希值，您可以使用git ls-remote并验证打印的哈希值的长度。

请注意，没有主要伪造支持 SHA-256，因此此类存储库无法上传到它们。

Answer 2

根据 git-init 版本 2.30.0 的手册页，sha-256 支持仍被认为是实验性的：

实际上，Git 2.42（2023 年第 3 季度）淡化了对 SHA-256 存储库的警告，这是一种实验性的好奇心。
目前尚不支持它们与传统 SHA-1 存储库进行互操作，但目前还没有计划对 SHA-256 存储库进行重大更改，并且不再需要如此强烈的措辞警告。

请参阅Adam Majer ( )的提交 8e42eb0（2023 年 7 月 31 日）。^{（由Junio C Hamano 合并 -- --在提交 e48d9c7中，2023 年 8 月 7 日）}AdamMajer
gitster

doc: sha256 不再是实验性的

^{签字人： Adam Majer}

删除可怕的措辞，这些措辞基本上阻止人们使用 sha256 存储库，不是因为与 sha1 存储库的互操作性问题，而是因为担心他们的工作会突然在某些未来版本的 git 中变得不兼容。

我们应该清楚，目前 sha256 存储库无法与 sha1 存储库一起使用，但请停止使用可怕的词语。

git现在包含在其手册页中：

总是被使用。默认值为“sha1”。见于.--object-format​git init

object-format-disclaimer现在包含在其手册页中：

注意：目前，SHA-256 存储库和 SHA-1 存储库之间不存在互操作性。

从历史上看，我们警告过，当我们引入此类互操作性功能时，SHA-256 存储库稍后可能需要向后不兼容的更改。今天，我们只期望兼容的变化。此外，如果此类更改被证明是必要的，则可以预期使用当今的 Git 创建的 SHA-256 存储库将可供未来版本的 Git 使用而不会丢失数据。

Git 2.43（2023 年第 4 季度）添加了有关 SHA-256 哈希的更多详细信息：用于批量签入代码路径的“流”接口已缩小为目前仅接受 blob 对象，而没有真正的功能损失。

请参阅Eric W. Biederman ( )的提交 9eb5419（2023 年 9 月 26 日）。^{（由Junio C Hamano 合并 -- --在提交 3df51ea中，2023 年 10 月 10 日）}ebiederm
gitster

bulk-checkin：仅支持 blobindex_bulk_checkin

^{灵感来源：brian m. 卡尔森
签字人：“Eric W. Biederman”}

由于今天编写的代码index_bulk_checkin仅接受 blob。
删除枚举object_type参数并将其重命名index_bulk_checkin为index_blob_bulk_checkin, index_streamto index_blob_stream, deflate_to_packto deflate_blob_to_pack, stream_to_packtostream_blob_to_pack,以使其明确。

index_bulk_checkin不支持提交、标签或树没有任何缺点，因为目前不支持它，并且设计上较小的提交、标签和树不存在构建要解决的问题。

在我们开始添加代码来支持哈希函数转换之前，支持其他对象类型并index_bulk_checkin没有真正的额外成本，只是需要一个额外的函数参数来了解对象类型是什么。
一旦我们开始哈希函数转换，情况就不是这样了。

哈希函数转换文档指定compatObjectFormat启用的存储库将计算并存储存储库中每个对象的 SHA-1 和 SHA-256 哈希值。

这是一个挑战，因为它不仅仅是同一对象上的附加哈希。
相反，哈希函数转换文档指定兼容性哈希（用 指定compatObjectFormat）是在另一个 git 存储库（其存储哈希（用 objectFormat 指定）将存储）的等效对象上计算的。
当比较使用不同存储哈希函数构建的等效存储库时，嵌入在用于引用其他对象的对象中的 oid 不同，并且对象内签名的位置也不同。

由于 blob 对象既没有引用其他对象的 oid，也没有存储的签名，因此它们的存储哈希和兼容性哈希是在同一对象上计算的。

其他类型的对象：树、提交和标签，都存储引用其他对象的 oid。
签名存储在提交和标记对象中。
由于 oid 和存储签名的标签在使用不同存储哈希构建的存储库中大小不同，因此等效对象的大小也不同。

当计算添加的每个对象的 SHA-1 和 SHA-256 时，该版本index_bulk_checkin不仅支持 blob，还需要不同的、更昂贵的结构。
该结构更昂贵，因为需要临时缓冲需要计算兼容性哈希的等效对象。

需要一个临时对象，因为在计算对象的哈希之前，需要计算其对象头。
对象头的成员之一是对象的整个大小。
要了解等效对象的大小，需要对原始对象进行完整传递，因为树、提交和标签由可变数量的可变大小的片段组成。
不幸的是，没有公式可以仅根据原始对象的大小来计算等效对象的大小。

index_bulk_checkin通过限制仅对 blob 进行操作来避免所有这些未来的并发症。

Answer 3

根据版本 2.30.0的手册页git-init，sha-256 支持仍被认为是实验性的：

--object-format=<format

    Specify the given object format (hash algorithm) for the
    repository. The valid values are sha1 and (if enabled) sha256.
    sha1 is the default.

    THIS OPTION IS EXPERIMENTAL! SHA-256 support is experimental and
    still in an early stage. A SHA-256 repository will in general not
    be able to share work with "regular" SHA-1 repositories. It should
    be assumed that, e.g., Git internal file formats in relation to
    SHA-256 repositories may change in backwards-incompatible ways.
    Only use --object-format=sha256 for testing purposes.