问题描述
我正在通过 man gitglossary 进行学习，而这一个术语已经躲过了我，因为它没有在术语表中定义过。
它仅被引用两次（添加了星号）：
备用对象数据库
通过**交替机制**，一个存储库可以从另一个对象数据库中继承其
对象数据库的一部分，该数据库称为
alternate。
存储库
一个refs集合以及一个包含
的对象数据库，这些对象可以从refs中访问，可能伴随着
元数据从一个或多个porcelains 。存储库可以通过** alternates mechanism **与其他存储库共享
对象数据库。
这里提到的交替机制是什么？
简短的回答是，您可以将任何现有的git存储库指向任何数量的其他现有git存储库 - 特别是指向它们的 code> .git / objects 目录 - 之后你的git将在你自己的
.git / objects 目录和列出的所有其他列表（按列表顺序）。 更难描述的是您可能想要做的 这个。
如果你知道git如何在内部工作，它会有所帮助。在git中，标识符可以很快地解决它们的哈希ID：
$ git rev-parse master
3266f25e27f69edbfc513a3b3cfd3987a89beff2
Git然后查找与此ID对应的对象。在这种情况下，该对象是一个提交。如果你的目标是对提交进行一些操作（比如检查它，或者将其与其他提交进行比较），git将读取包含树ID的对象。 Git然后读取树对象;它包含额外的树和文件（blob）的名称，以及它们的ID，git读取这些对象以查找文件以及递归的子树及其文件。
现在假设您有一个非常大的存储库的现有副本，并且 - 无论出于何种原因 - 您想要再次克隆它（可能需要在单独的分支中使用单独的克隆）。 您可以告诉git所有原始对象在第一个存储库中可用，而不是创建原始存储库的第二个完整副本。一旦git有交替条目，它将能够找到这些对象，并且不需要下载它们。
在第二个克隆中创建的新对象当然会，只需进入第二个克隆;但是这节省了大量的时间和空间。在一台机器上的共享克隆一般直接链接到其他克隆的对象，使用Unix风格的硬链接，但如果这是不可能的，交替机制提供了另一种方式来做同样的事情，交替的危险是如果第一个克隆被删除，对象就会消失;硬链接没有这个缺陷，一个<$ c
$ b $参考克隆也使用了交替机制。）
最好的答案可能是in来源。 ： - ）
现在git可以提供多个工作树单一克隆，这比以前重要。
I'm studying through man gitglossary, and this one term has eluded me—because it isn't defined in the glossary at all.
It's referred to only twice (asterisks added):
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**.
What is the "alternates mechanism" that is referred to here?
The short answer is that you can point any existing git repository to any number of additional existing git repositories—specifically, to their .git/objects directories—after which your git will search for objects in both your own .git/objects directory and all the other listed ones (in listing order).
What's tougher to describe is why you might want to do this.
It helps if you know how git works internally. In git, identifiers tend to resolve fairly quickly to their hash ID:
$ git rev-parse master
3266f25e27f69edbfc513a3b3cfd3987a89beff2
Git then looks for the object corresponding to this ID. In this case, the object is a commit. If your goal is to do something with the commit—such as check it out, or diff it against some other commit—git reads the object, which contains the ID of a tree. Git then reads the tree object; this contains the names of additional trees and files ("blobs"), and their IDs, and git reads those objects to find the files and, recursively, the sub-trees and their files.
Now suppose that you have an existing copy of a very large repository, and—for whatever reason—you want to clone it again (perhaps to have a separate clone for working in a separate branch). Rather than making a second complete copy of the original repository, you can tell git that all the original objects are available in the first repository. Once git has the alternates entry, it will be able to find those objects and will not need to download them.
New objects you create in this second clone will, of course, just go in the second clone; but this saves a lot of time and space.
("Shared" clones on a single machine generally link directly to the other clone's objects, using Unix-style hard links, but if this is not possible, the alternates mechanism provides another way to do the same thing. The danger with alternates is that if the first clone is removed, the objects go away; hard links don't have this flaw. A --reference clone also uses the alternates mechanism.)
As for:
the best answer is probably "in the source". :-)
Now that git has the ability to provide multiple work trees from a single clone, this is less important than it once was.
这篇关于什么是Git“替代机制”？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！