什么是 Git“替代机制”？答案

【问题标题】：What is the Git "alternates mechanism"?什么是 Git“替代机制”？
【发布时间】：2016-03-21 05:20:45
【问题描述】：

我正在通过man gitglossary 学习，而这个术语让我无法理解——因为它根本没有在词汇表中定义。

它只被引用了两次（添加了星号）：

   alternate object database
       Via the **alternates mechanism**, a repository can inherit part of its
       object database from another object database, which is called
       "alternate".

   repository
       A collection of refs together with an object database containing
       all objects which are reachable from the refs, possibly accompanied
       by meta data from one or more porcelains. A repository can share an
       object database with other repositories via **alternates mechanism**.

这里提到的“交替机制”是什么？

【问题讨论】：

标签： git

【解决方案1】：

简短的回答是，您可以将任何现有的 git 存储库指向任意数量的 additional 现有 git 存储库——特别是指向它们的 .git/objects 目录——之后你的 git 将在这两个目录中搜索对象您自己的.git/objects 目录和所有其他列出的目录（按列出顺序）。

更难描述的是为什么你可能想要这样做。

如果您了解 git 内部的工作原理，这会有所帮助。在 git 中，标识符往往会很快地解析为它们的哈希 ID：

$ git rev-parse master
3266f25e27f69edbfc513a3b3cfd3987a89beff2

Git 然后查找与此 ID 对应的对象。在这种情况下，对象是一个提交。如果你的目标是对提交做一些事情——比如检查它，或者将它与其他提交进行比较——git 会读取包含树 ID 的对象。然后 Git 读取树对象；这包含其他树和文件（“blob”）的名称及其 ID，git 读取这些对象以查找文件，并以递归方式查找子树及其文件。

现在假设您有一个非常大的存储库的现有副本，并且 - 无论出于何种原因 - 您想要再次克隆它（也许有一个单独的克隆以便在单独的分支中工作）。^{1 sup> 您可以告诉 git 所有原始对象都在 first 存储库中可用，而不是制作原始存储库的第二个完整副本。一旦 git 有了alternates 条目，它将能够找到这些对象，并且不需要下载它们。}

您在第二个克隆中创建的新对象当然会进入第二个克隆；但是这样可以节省很多时间和空间。

(单台机器上的“共享”克隆通常直接链接到其他克隆的对象，使用 Unix 风格的硬链接，但如果这不可能，替代机制提供了另一种方法来做同样的事情。 alters 是，如果第一个克隆被删除，对象就会消失；硬链接没有这个缺陷。--reference 克隆也使用了alternates 机制。）

至于：

定义它的官方文档在哪里？

最好的答案可能是“在源头”。 :-)

¹现在 git 能够从一个克隆中提供多个工作树，这已经不像以前那么重要了。

【讨论】：

我已经添加了一个答案来涵盖“源代码”部分；）当然是您的答案+1。
感谢您对我这个棘手的问题的出色而彻底的回答。 :) 我还有一个你可能想试一试的：stackoverflow.com/q/62497089/5419599
看起来 VonC 比我快得多。 :-)

【解决方案2】：

关于 git 本身，第一次提到“备用对象数据库位置”是在 commit ace1534（2005 年 5 月，git v0.99）

引入 SHA1_FILE_DIRECTORIES 以支持多个对象数据库。

SHA1_FILE_DIRECTORIES 环境变量是冒号分隔的路径用于查找在通常位置找不到的 SHA1 文件阅读。创建新的 SHA1 文件不使用此替代对象数据库定位机制。这对于归档较旧的、很少使用的文件很有用使用的对象到单独的目录中。

这是第一个示例，很快从 git 中删除（2005 年 9 月，commit a9ab586）

备用对象数据库struct 在commit 9a217f2（2005 年 6 月，v0.99）中正式引入cache.h#L236-L239。

今天 (most recent cache.h)，struct 仍然存在，但这次使用 链接机制，于 2005 年 8 月推出，v0.99.5，commit d5a63b9。

extern struct alternate_object_database {
    struct alternate_object_database *next;
    char *name;
    char base[FLEX_ARRAY]; /* more */
} *alt_odb_list;

准备备用对象数据库注册表。

变量alt_odb_list指向struct alternate_object_database列表。

此列表中的元素来自冒号分隔的ALTERNATE_DB_ENVIRONMENT 环境变量和GIT_OBJECT_DIRECTORY/info/alternates 中的非空元素，其内容与该环境变量的格式完全相同。

它的基点指向包含“/the/directory/corresponding/to/.git/objects/...”的静态分配缓冲区，而在上例中，它的名称指向“.git/objects/”末尾的斜线之后，并且有足够的空间容纳 40 字节十六进制 SHA1，第一级间接的额外斜线和终止 NUL。

这可能是你可以在 git 源代码中找到的“替代机制”最接近的定义。

您可以看到alternate database implementation in libgit2 的示例（Libgit2 是用纯 C 编写的 Git 实现）

Git 存储库的核心只有两个主要结构，一切都基于它：object database 和 ref database。

对象数据库是存储所有数据的地方。所有文件的内容、目录结构、提交、所有内容都进入对象数据库。然而，对象数据库的非凡之处在于它本质上只是一个键值存储。

Git 使用基于哈希的检索将数据存储在对象数据库中，这意味着存储的键是值的 (SHA1) 哈希。
这有一些有趣的进一步含义：对象数据库中的值本质上是不可变的，您不需要更新操作。

您可以提供自己的后端实现并做任何您想做的事情，而不是以 Git 通常的方式存储对象数据库和引用数据库（在平面文件中）。

Git 传统上支持：

odb_loose 实现了松散文件格式后端。它访问对象目录中单独文件中的每个对象，每个文件的名称对应于其内容的 SHA1 哈希值。

odb_pack 实现了 packfile 后端。它访问 Git packfiles 中的对象，这是一种文件格式，用于节省空间的对象存储，以及在推送或拉取时传输对象。

（另见“Is the git binary diff algorithm (delta storage) standardized?”）

【讨论】：