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

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

Git使用增量编码将一些对象存储在packfiles中。但是，你不希望有播放的每一个修改过，以获得最新的版本在给定的文件，这样的Git还具有存储和文件内容偶尔的快照。“解决差异”是确保所有内容保持一致的步骤。

这是 Pro Git书的“ Git Internals”部分中的一章，该章可以在线获取，并对此进行了讨论。

的阶段为git clone：

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

“解决增量”是第二阶段显示的消息，索引了打包文件（“ git index-pack”）。

打包文件中没有实际的对象ID，只有对象内容。因此，要确定对象ID是什么，git必须对数据包中的每个对象执行decompress + SHA1生成对象ID，然后将其写入索引文件。

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

总而言之，“解决增量”阶段涉及对整个回购数据库进行解压缩和校验和，这并不奇怪，需要相当长的时间。估计解压缩和计算SHA1实际上比应用delta命令花费更多的时间。

在后续提取的情况下，接收到的包文件可能包含对接收git预期已经具有的其他对象的引用（作为增量对象库）。在这种情况下，接收方git实际上会重写接收到的包文件以包括任何此类引用的对象，从而使任何存储的包文件都是自给自足的。这可能是消息“解决增量”的来源。

琥珀似乎正在描述Mercurial或类似产品使用的对象模型。Git不会存储对象的后续版本之间的增量，而是每次都存储对象的完整快照。然后，它使用增量压缩来压缩这些快照，从而尝试找到要使用的良好增量，而不管它们在历史记录中的位置如何。