Git如何计算要获取的提交

我知道git fetch做什么，以及如何使用这个命令

我对内部内容感兴趣：Git如何确定要传输的确切提交

例如下面的情况

本地回购：

A - B - C - D master
     \  \- E - F feature1
      \- G feature2

来源：

A - B - C - D - D1 - D2 master
     \  \- E - F - F1 - F2 feature1
      \- G - G1 feature2

git fetch

需要下载提交D1、D2、F1、F2和G1

很天真，我的git客户端可以将本地提交SHA列表（a、B、C、D、E、F、G）发送到远程存储库。远程存储库将找到所有不在我列表中的SHA（D1、D2、F1、F2、G1），并将它们发送回我。对于大型存储库，这将涉及发送大量数据和进行大量计算。发送到远程回购的数据将与提交的总数成比例

我相信会采用更聪明的方法

仅发送每个分支（D、F、G）的尖端的SHA就足够了吗？跟踪远程repo的父级可以确定两个repo共享的提交，并仅确定缺少的提交。发送到远程回购的数据将与（未合并的）分支总数成比例，这通常远低于提交的数量

它是否在所有情况下都有效（分支后、前、重定基础）

还有其他想法吗？我期待一个基于图论的漂亮解决方案：-）

仅发送每个分支（D、F、G）的尖端的SHA就足够了吗

经常，是的，但不总是。在这种情况下，它可以完美地工作：接收Git可以宣布它拥有这三个散列ID，并且由于发送Git拥有这些提交，因此发送Git可以由此推断，只要接收Git不是浅存储库，接收Git就拥有这些提交和所有前置

“不总是”的线索在上面的陈述中：如果接收的Git是一个浅克隆，它可能在这里缺少一些祖先。如果接收Git中的分支提示提交是针对发送方中不存在的提交，则它们的哈希ID不会向发送方传递任何信息

---

在这些情况下，我们依靠“拥有”和“想要”。发送方将其ref名称和散列ID发送给接收方。接受者可以分辨出他是否有这些物品。如果没有，并且接收者想要它们，他就发出信号说他“想要”它们。发送方需要为这些提交的父级提供额外的哈希ID；接收者将指出他是否拥有这些信息。在所有情况下，拥有一些提交散列ID表示一个人拥有所有祖先，浅存储库除外（这些将明显的优化弄得一团糟，我还没有深入到Git源代码中，以了解是否有更多关于浅层克隆的特殊情况——移植点在接收器中是已知的，但我在协议描述中没有看到允许公布它们的内容）.

谢谢你的链接。我不久前确实读过这本书，但我一定只是略过了这一章：-），所以这个过程似乎更具互动性，涉及到信息交换（这也在《博士》链接的那一章中有所说明）。老实说，我完全忘记了浅层存储库的情况，这显然使事情复杂化了很多。