Question

我正在通过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**.

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

Answer 1

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

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

如果您知道git如何在内部工作，这会有所帮助。在git中，标识符倾向于快速解析其哈希ID：

$ git rev-parse master
3266f25e27f69edbfc513a3b3cfd3987a89beff2

然后，Git会查找与此ID对应的对象。在这种情况下，对象是提交。如果您的目标是使用提交执行某些操作（例如检查它），或者将其与其他提交进行区分，则会读取包含树ID的对象。然后Git读取树对象;它包含其他树和文件的名称（＆＃34; blobs＆＃34;）及其ID，git读取这些对象以查找文件，并递归地查找子树及其文件。

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

您在第二个克隆中创建的新对象当然只会进入第二个克隆;但这节省了大量的时间和空间。

（＆＃34;共享＆＃34;单个机器上的克隆通常使用Unix风格的硬链接直接链接到其他克隆的对象，但如果这不可能，则交替机制提供另一种方式替换的危险在于，如果移除第一个克隆，则对象消失;硬链接没有这个缺陷。--reference克隆也使用替换机制。）< / p>

至于：

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

最好的答案可能是＃34;来源＆＃34;。： - ）

¹既然git能够从单个克隆中提供多个工作树，那么它就不像以前那样重要了。

Answer 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，{{3 }}

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来源中找到的“替代机制”最接近的定义。

你可以看到一个commit d5a63b9的例子（alternate database implementation in libgit2是用纯C编写的Git的实现）

Git仓库的核心只有两个主要结构，一切都基于：对象数据库，并且有 ref数据库。 / p>
对象数据库是存储所有数据的地方。所有文件的内容，目录结构，提交，所有内容都在对象数据库中。然而，对象数据库的显着之处在于它基本上只是一个键值存储。

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

Libgit2

而不是以Git通常的方式存储对象数据库和ref数据库 - 在平面文件中 - 您可以提供自己的后端实现并执行任何您想要的操作。

Git传统上支持：


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

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

（另见“”）

什么是Git“替代机制”？

2 个答案:

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