我一直在观察我们的 Azure Devops Server 2019 服务器的一些非常奇怪的行为。偶尔提取会拉下比完成提取所需的更多的数据。这通常发生在大型合并中，但是昨天它发生在一个相对简单的合并中。
我有两个分支，大约有十几个提交。我在我的机器上完全检查了两个分支。我使用拉取请求将它们合并在一起。在拉取请求完成后从我的机器上进行提取时，它需要拉取 28,000 个文件和 2GB 的信息，并且需要很长时间才能拉取。
任何想法为什么会发生这种情况？合并没有任何冲突，自上次合并以来，只有合并的一侧发生了变化。（我们的合并表明来自被合并分支的一组环境配置更改是无关紧要的。）除了干净的合并提交之外的所有提交都已经在我的机器上并已签出。这应该是一个非常简单的操作，不需要重新发送我的存储库的相当一部分。
我能够找到 Azure Devops Server 中缺陷的根本问题。在 fetch_pack/upload_pack 协商阶段，Azure Devops Server 似乎过早地响应了“ACK 就绪”。尽管有两个完整的分支历史未被发现（对于当前在需要列表中的分支），但 Azure Devops 准备就绪并开始包传输。
我能够解决我们遇到的主要案例，但不能解决我在这个问题中使用的初始说明。
遇到此类问题的大多数用户是由于启用了有限引用，并且一个大型有限引用通过“我们的”合并加入了历史链。这与我经历的特定案例无关，因为我在本地有相关的历史，但其他人可能会遇到这个问题，因为合并包括历史上更早的以前未引用的历史。
现在我还不能重现我最初的错误，所以我必须等到下一次看到它（它往往发生在分支切割周围，隐藏的历史也不是一个因素。）但是如果其他人有任何其他想法，我很想听听他们的意见。
如果其他人遇到类似的错误，使用GIT_TRACE_PACKET获取拥有和想要的列表非常有助于您了解历史并找出被获取对象的来源。