在.git/objects目录中，有info子目录。它是干什么用的？我知道.git/objects目录用于什么，.git/objects/pack目录是什么。但我找不到.git/objects/info目录的信息。它可能位于表面上，但info过于通用的名称无法在谷歌搜索 - 太多无关的结果。
答案 0 :(得分：6)
Repository layout documentation：
<强>对象/信息
有关对象库的其他信息将记录在此目录中。<强>对象/信息/包
此文件用于帮助哑传输发现此对象库中可用的包。无论何时添加或删除包，都应运行git update-server-info，以便在为哑运输发布存储库时使该文件保持最新。 git repack默认执行此操作。<强>对象/信息/交替
此文件记录此对象存储借用对象的备用对象存储库的路径，每行一个路径名。请注意，不仅本机Git工具在本地使用它，而且HTTP提取器也尝试远程使用它;如果您在替换文件中有相对路径（相对于对象数据库，而不是存储库！），这通常会起作用，但如果您使用绝对路径它将无法工作，除非文件系统和Web URL中的绝对路径相同。另请参见objects / info / http-alternates。<强>对象/信息/ HTTP的交替
此文件记录此对象存储借用对象的备用对象存储库的URL，以便在通过HTTP获取存储库时使用。
所以它纯粹是内部的git。
例如：
$ cat .git/objects/info/packs
P pack-fac58f9273f12d454896cdc6070b9607e271e530.pack
$ ls -1 .git/objects/pack/
pack-597bfea331852c930d2cd014e0328c458417ea05.pack
pack-d5589be9a1ca818d38efb0e9f185cc816f4749ad.pack
pack-fac58f9273f12d454896cdc6070b9607e271e530.idx
pack-fac58f9273f12d454896cdc6070b9607e271e530.pack
它在http.c#http_get_info_packs使用的https-push.c#fetch_indices中使用。
答案 1 :(得分：1)
信息/替代的概念可以追溯到 With Git 1.4（2006 年第二季度），
参见 commit 0438402 的 commit dd05ea1、commit c2f493a、commit 178613c、commit cf9dc65、Martin Waitz (tali)（2006 年 5 月 7 日）。
请参阅 commit fd60aca 的 commit 6fe31e2，Junio C Hamano (gitster)（2006 年 5 月 7 日）。
请参阅 commit d92f1dc 的 Peter Hagervall (phagervall)（2006 年 5 月 7 日）。
请参阅 commit 5d8ee9c 的 Pavel Roskin (proski)（2006 年 5 月 7 日）。
请参阅 commit 245f102 的 Matthias Lederhofer (matled)（2006 年 5 月 7 日）。
请参阅 commit be65e7d 的 Johannes Schindelin (dscho)（2006 年 5 月 7 日）。
（由 Junio C Hamano -- gitster -- 于 commit 7f49806 合并，2006 年 5 月 7 日）
c2f493a4ae：传递读取替代项签字人：Martin Waitz
<块引用>当添加一个替代对象存储时，也从它的信息/替代文件中添加条目。
相对条目只允许在当前存储库中。
通过多个存储库的循环和重复替代将被忽略。
为了确保没有任何问题，不允许使用信息/替代品构建深层嵌套。
但最近（2021 年），它随着 Git 2.33（2021 年第 3 季度）而发展，为具有许多替代对象存储的存储库增加了优化。
请参阅 commit 92d8ed8 的 commit 90e07f0、commit 33f379e、commit 407532f、commit cf2dc1c、Eric Wong (ele828)（2021 年 7 月 7 日）。
（2021 年 7 月 28 日于 Junio C Hamano -- gitster -- 被 commit e5cc59c 合并）
oidtree：crit-bitodb_loose_cache 树
签字人：Eric Wong
<块引用>这为每个 struct object_directory`' 节省了 8K，这意味着在我涉及 100K 替代品的情况下它节省了大约 800MB（其中一半或更多的替代品不太可能容纳松散的对象）。
这是由两部分实现的：一个通用的、无分配的 cbtree 和在它之上的 oidtree 包装器。
后者提供使用 alloc_state 作为内存池的分配，以提高局部性并减少 free(3) 开销。
与 oid-array 不同，crit-bit tree 不需要排序。
性能受密钥长度限制，对于固定在 oidtree 的 sizeof(struct object_id)。
不需要像 oid-oidtrees 那样使用 256 array 来减轻 O(n log n) 开销。
作为前缀树，它本机适用于通过 find_short_object_filename 中的前缀限制迭代扩展短对象 ID。
在我繁忙的工作站上，p4205 的性能似乎基本没有变化 (+/-8%)。
在没有松散对象的情况下启动总共 100K 的交替似乎在热缓存上快了 10-20%。
（节省 800MB 内存意味着内核 FS 缓存有更多内存）。
通用的 cbtree 实现确实给 oidtree 带来了一些额外的开销，因为它在“struct object_id"”上使用了 memcmp(3)，因此在比较 SHA-1 存储库上的 12 个额外字节时会浪费周期。
我还没有探索过如何减少这种开销，但我希望我们的代码库中有很多地方需要对此进行调查。