当git说它正在“解决三角洲”时，它实际上在做什么？

Question

在第一次克隆存储库时，git首先接收对象（这很明显），然后花费大约相同的时间“解析增量”。在克隆的这个阶段实际发生了什么？

Answer 1

git clone的各个阶段是：

1. 接收repo数据库中所有对象的“pack”文件
2. 为收到的包创建索引文件
3. 查看头部修订版（显然是非裸仓库）

“Resolving deltas”是为第二阶段显示的消息，索引包文件（“git index-pack”）。

不的包文件中包含实际的对象ID，只包含对象内容。因此，为了确定对象ID是什么，git必须对包中的每个对象进行解压缩+ SHA1以生成对象ID，然后将其写入索引文件。

包文件中的对象可以存储为增量，即对一些其他对象进行的一系列改变。在这种情况下，git需要检索基础对象，应用命令和SHA1结果。可能必须通过应用一系列delta命令来派生基础对象本身。 （即使在克隆的情况下，已经遇到过基础对象，但在内存中缓存了多少制造对象的限制。）

总之，“解析增量”阶段涉及对整个仓库数据库进行解压缩和校验和处理，这不足为奇地花费了很长时间。据推测，解压缩和计算SHA1实际上比应用delta命令需要更多的时间。

在后续提取的情况下，所接收的包文件可以包含对接收git预期已经具有的其他对象的引用（作为增量对象基础）。在这种情况下，接收git实际上重写接收的包文件以包括任何这样的引用对象，以便任何存储的包文件是自给自足的。这可能是消息“解决增量”的起源。

Answer 2

Git使用delta encoding来存储packfiles中的一些对象。但是，您不希望为了获取当前版本而回放给定文件上的每个永远的更改，因此Git也会偶尔存储文件内容的快照。 “解决增量”是确保所有这些保持一致的步骤。

来自Pro Git书籍的“Git Internals”部分的

Here's a chapter可以在网上找到。

Answer 3

Amber似乎在描述Mercurial或类似用途的对象模型。 Git不会在对象的后续版本之间存储增量，而是每次都存储对象的完整快照。然后，它使用增量压缩压缩这些快照，试图找到要使用的良好增量，无论历史记录在何处存在。