我正在研究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**.
Run Code Online (Sandbox Code Playgroud)
这里提到的"替代机制"是什么?
tor*_*rek 16
简短的回答是,您可以将任何现有的git存储库指向任意数量的其他现有git存储库 - 特别是指向其.git/objects目录 - 之后您的git将在您自己的.git/objects目录和所有其他列出的目录中搜索对象(按列表顺序) ).
更难描述的是为什么你可能想要这样做.
如果你知道git如何在内部工作,它会有所帮助.在git中,标识符倾向于快速解析其哈希ID:
$ git rev-parse master
3266f25e27f69edbfc513a3b3cfd3987a89beff2
Run Code Online (Sandbox Code Playgroud)
然后Git查找与此ID对应的对象.在这种情况下,对象是提交.如果您的目标是使用提交执行某些操作(例如检查它),或者将其与其他提交进行区分,则会读取包含树ID的对象.然后Git读取树对象; 这包含其他树和文件("blob")的名称及其ID,git读取这些对象以查找文件,并递归地查找子树及其文件.
现在假设您有一个非常大的存储库的现有副本,并且 - 无论出于何种原因 - 您想要再次克隆它(可能要在单独的分支中使用单独的克隆).1 您可以告诉git所有原始对象在第一个存储库中都可用,而不是制作原始存储库的第二个完整副本.一旦git具有alternates条目,它将能够找到这些对象,而不需要下载它们.
您在第二个克隆中创建的新对象当然只会进入第二个克隆; 但这节省了大量的时间和空间.
(单个机器上的"共享"克隆通常使用Unix风格的硬链接直接链接到其他克隆的对象,但如果这不可能,则交替机制提供另一种方法来执行相同的操作.交替使用的危险是如果删除第一个克隆,则对象消失;硬链接没有此缺陷.--reference克隆也使用替换机制.)
至于:
定义它的官方文档在哪里?
最好的答案可能是"在源头".:-)
1既然git能够从单个克隆中提供多个工作树,那么这一点就不像以前那么重要了.
关于git本身,第一次提到"备用对象数据库位置"是在提交ace1534(2005年5月,git v0.99)中完成的.
引入SHA1_FILE_DIRECTORIES以支持多个对象数据库.
SHA1_FILE_DIRECTORIES环境变量是一个冒号分隔的路径,用于查找在通常的读取位置找不到的SHA1文件.创建新的SHA1文件不使用此备用对象数据库位置机制.这对于将较旧的,很少使用的对象存档到单独的目录中很有用.
这是第一个例子,很快从git中删除(2005年9月,提交a9ab586)
备用对象数据库struct在提交9a217f2(2005年6月,v0.99)中正式引入cache.h#L236-L239.
今天(最近的cache.h),struct仍然存在,但这次使用链接机制,在2005年8月引入,v0.99.5,提交d5a63b9.
extern struct alternate_object_database {
struct alternate_object_database *next;
char *name;
char base[FLEX_ARRAY]; /* more */
} *alt_odb_list;
Run Code Online (Sandbox Code Playgroud)
准备备用对象数据库注册表.
变量
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源中找到的"替代机制"最接近的定义.
您可以在libgit2中看到备用数据库实现的示例(Libgit2是用纯C编写的Git实现)
Git仓库的核心只有两个主要结构,一切都基于:有对象数据库,还有ref数据库.
对象数据库是存储所有数据的地方.所有文件的内容,目录结构,提交,所有内容都在对象数据库中.然而,对象数据库的显着之处在于它基本上只是一个键值存储.
Git使用基于散列的检索将数据存储在对象数据库中,这意味着存储的键是值的(SHA1)哈希值.
这有一些有趣的进一步含义:对象数据库中的值基本上是不可变的,您不需要更新操作.
而不是像Git通常那样存储对象数据库和ref数据库 - 在平面文件中 - 你可以提供自己的后端实现并做任何你想做的事情.
Git传统上支持:
odb_loose实现松散的文件格式后端.它访问对象目录中单独文件中的每个对象,每个文件的名称对应于其内容的SHA1哈希.odb_pack实现packfile后端.它访问Git packfiles中的对象,这是一种文件格式,用于节省空间的对象存储,以及在推或拉时传输对象.
(另请参阅" git二进制差异算法(增量存储)是否已标准化? ")