在.git/objects目录中，有一个名为info的子目录。它是用来做什么的？我知道 .git/objects目录的用途以及.git/objects/pack目录的作用，但是我找不到关于.git/objects/info目录的信息。它可能存在于某个表面上，但info是一个过于通用的名称，在Google中搜索会出现太多无关的结果。
什么是`.git/objects/info`目录？
8
- courses.indepth.dev
1
4为什么会是-1？这是一个合理的问题。（计数器+1） - silvio
2个回答
10
objects/info
记录有关对象存储的其他信息。objects/info/packs
此文件可帮助“愚蠢”的传输发现此对象存储中可用的包。每当添加或删除一个包时，如果将存储库发布给愚蠢的传输，则应运行 git update-server-info 以使此文件保持最新状态。git repack 默认会这样做。objects/info/alternates
此文件记录了此对象存储从中借用对象的备用对象存储路径，每行一个路径名。请注意，不仅本机 Git 工具在本地使用它，而且 HTTP 获取器也尝试在远程使用它；如果您的备用文件中使用相对路径（相对于对象数据库而不是存储库！），则通常可以工作，但如果您使用绝对路径，则除非文件系统和 web URL 中的绝对路径相同，否则它将无法正常工作。请参见 objects/info/http-alternates。objects/info/http-alternates
此文件记录了此对象存储从中借用对象的备用对象存储的网址，在通过 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使用。
- zigarn
1
1我更新了我的回答，但它仅涉及Git内部。您可以通过在代码中搜索“info/packs”来查找：https://github.com/git/git/search?p=1&q=%22info%2Fpacks%22&type=&utf8=%E2%9C%93 - zigarn
1
信息/备选项的概念可以追溯到Git 1.4（2006年第二季度）。
请查看提交记录0438402, 提交记录dd05ea1, 提交记录c2f493a, 提交记录178613c, 提交记录cf9dc65 (2006年5月7日)，作者为Martin Waitz (tali)。
请查看提交记录fd60aca, 提交记录6fe31e2 (2006年5月7日)，作者为Junio C Hamano (gitster)。
请查看提交记录d92f1dc (2006年5月7日)，作者为Peter Hagervall (phagervall)。
请查看提交记录5d8ee9c (2006年5月7日)，作者为Pavel Roskin (proski)。
请查看提交记录245f102 (2006年5月7日)，作者为Matthias Lederhofer (matled)。
请查看提交记录be65e7d (2006年5月7日)，作者为Johannes Schindelin (dscho)。
(由Junio C Hamano -- gitster --在提交记录7f49806中合并，2006年5月7日)
c2f493a4ae:传递性读取替代物
签名：Martin Waitz
当添加一个替代对象存储时，还要添加来自其info/alternates文件的条目。
相对条目仅允许在当前存储库中使用。
循环和重复替代通过多个存储库被忽略。
为了确保不会出现任何问题，不允许使用info/alternates构建深层嵌套级别。
但最近（2021年），它随着Git 2.33（2021年第三季度）的推出而发展，为具有许多替代对象存储的存储库添加了优化。
查看 提交 92d8ed8，提交 90e07f0，提交 33f379e，提交 407532f，提交 cf2dc1c (2021年7月7日) 由 Eric Wong (ele828) 提交。
(由 Junio C Hamano -- gitster -- 合并于 提交 e5cc59c，2021年7月28日)
这可以为每个`struct object_directory`对象节省8K，这意味着在涉及100K个交替物的我的情况下，可以节省约800MB（其中一半或更多的交替物不太可能保存松散的对象）。
oidtree: 一种用于odb_loose_cache的crit-bit树签名作者: Eric Wong
这分为两部分实现：一个通用的、无需分配的`cbtree`和基于它的`oidtree`包装器。后者使用`alloc_state`作为内存池进行分配，以改善局部性并减少`free(3)`的开销。
与`oid-array`不同，
crit-bit tree不需要排序。性能受键长度限制，在`oidtree`中，它固定为`sizeof(struct object_id)`。不需要有256个`oidtrees`来缓解O(n log n)的开销，就像我们使用`oid-array`一样。作为前缀字典树，它天生适合通过前缀限制迭代在`find_short_object_filename`中扩展短对象ID。
在我繁忙的工作站上，p4205的性能似乎大致不变（+/-8%）。在热缓存中启动总共100K个备用项且没有松散对象的速度似乎比较快，大约快10-20%。（内存节省了800MB，这意味着内核FS缓存有更多的内存）。
通用的`cbtree`实现对于`oidtree`确实会带来一些额外的开销，因为它在“`struct object_id`”上使用`memcmp(3)`，因此在SHA-1存储库中浪费了比较12个额外字节的周期。我还没有探索减少这种开销，但我希望我们的代码库中有许多地方需要调查这个问题。
而且，仍然在 Git 2.33 (2021年第三季度) 中，修复了一个构建问题：
请查看提交 581a3bb (2021年8月6日) ，由René Scharfe (rscharfe)提交。
请查看提交 dd3c8a7，提交 1482594 (2021年8月8日) ，由Carlo Marcelo Arenas Belón (carenas)提交。
(合并自Junio C Hamano -- gitster --在提交 7cfaa86，2021年8月11日)
object-file: 使用位掩码进行无符号算术运算
Signed-off-by: René Scharfe
33f379e（2021年7月7日，Git v2.33.0-rc0 -- 合并列在 批次 #7中）将一个浪费的256字节数组替换为一个32字节的数组和位运算。
掩码计算将int类型的字面量1左移0到31位之间的任意值。
UndefinedBehaviorSanitizer不喜欢这样做，会报告：
object-file.c:2477:18: 运行时错误：将1左移31位，无法用'type int'表示确保使用无符号1来避免这个问题。
size_t mask = 1 << (subdir_nr % word_bits);
size_t mask = 1u << (subdir_nr % word_bits); <==
- VonC
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接