git - Git Smart API 精简包计算是否可以考虑重用公共(public)子树？

Question

问:当 git 在 Smart Protocol 上推送没有共同历史的引用时, 在构建要发送的精简包时，是否可以考虑本地和 origin 之间已经共有的根或子树？

tl;dr

在使用和推送到远程 Git 存储库时考虑这种(不常见的)情况。

• 我有一个本地存储库，其中本地 master 指向具有 1110 个后代子树的树 a[0-9]/b[0-9]/c[0- 9].
• 远程 origin/master 与本地 master 提交是最新的，即相同的历史记录。它使用 ssh 协议(protocol)。
• 出于某种原因，我创建了一个本地分支 squashed。我将该分支设置为一个新的单根提交，但具有与 master 相同的内容/树。这可以通过 git commit-tree 来完成。所以这个分支只有一个提交，没有与 master 共同的提交，但是根树哈希是相同的，它指向 master 和 来源/主人。为了讨论这个问题，这是一个单一的/压缩的提交并不重要 - 任何历史重写回根提交，没有共同的历史都可以。
• git push origin HEAD # push squashed

通过观察大型存储库的性能和发送的对象数量，我怀疑 push、send-pack 和 receive- pack 和关于 Smart Protocol 的相关瘦包协商做类似的事情:

• 确认被推送的提交 squashed 与 origin 当前拥有的任何提交没有共同历史。
• 没有注意到 squashed 指向的树不仅在 origin 中，而且是当前 HEAD 的树引用
• 打包并发送所有内容。

在这种情况下，树是相同的。如果在 squashed 中进行了后续更改......要么是额外的提交，要么是更改 a0 中文件的新压缩，2 棵树(/ 和 a0) 会改变，其他 1109 不会改变。根树已更改，这意味着需要进行下一级搜索以查看是否值得搜索更多公共(public)子树。这可能需要启发式方法，因为如果不比较所有子树直至叶子，就不可能从任何特定深度的树中推断出共同后代树的数量。

当然，如果在推送的无共同历史记录中有多个提交，则需要为每个提交重复此协商。

智能 API 在考虑每次提交时可以考虑已经存在的公共(public)子树，或者至少是根树，这听起来合理吗？或者 Git 应该已经这样做了，而我的客户端或服务器有问题吗？

git 版本 2.8.2

Answer 1

检查 git 的源代码并尝试使用 git 守护进程和 GIT_TRACE_PACKET 表明您对它正在做的事情是正确的:git 仅在提交级别进行协商。如果历史没有共享，git 将不会检测到共享的内容。

Does it sound reasonable that the Smart API could consider already-held common sub-trees, or at the very least, the root-tree, as it considers each commit?

如果已经持有的公共(public)子树不能通过已经持有的公共(public)提交来识别，那么为了识别这些子树，它必须发送它们的 ID。

问题是，对于任何缺少完整读数的情况，我可以构建一个听起来似是而非的角落案例，发送任意大量的冗余数据——但每次都发送每个现有的子树 ID 以避免这种可能性显然是一个巨大的损失。不要忘记往返延迟非常昂贵。那么，当考虑在所有 提取中增加总体开销时，您在什么时候可能会花更多的时间进行谈判？如果您要争辩说某些特定的替代方法会节省总体时间，您将不得不展示实际生产流量的硬数据。

另请记住，您可以自己构建包。这并不难，您将对象 ID 提供给 git pack-objects pack 并将输出放入 .git/objects/pack，恭喜，您刚刚获取了这些对象进入那个 repo 协议(protocol)。