Git服务器并行/并发/多线程传输？

Question

在perforce中，我们可以启用并行同步/提交，这意味着如果有200个新文件需要从服务器中提取，那么p4v客户端将打开5-10个到服务器的连接并将并发文件并行拉到另一个文件。这对传输速度有很大的改善，这意味着单线程上30Mbps的差异或8个并发线程上的240Mbps差异，特别是因为我们的软件仓库每周都会收到10 GB的值。

我一直在环顾四周，看看是否有类似的东西，我可以启用我们的Gitlab服务器，但我还没有找到任何东西。这是我在这个主题上发现的唯一的东西，它只是一个请求git-annex：https://git-annex.branchable.com/forum/Feature_request__58___Multiple_concurrent_transfers/

有没有人知道这是否可能，如果是的话，你会如此友善，指向我在正确的方向？

谢谢！

Answer 1

Git当前通过单个连接传输内容。目前不可能通过其网络协议发送分块内容。由于torek mentionned git会执行一些处理来减少需要传输的数据的大小。所以git通常会通过单一连接传输比最终重建的内容更少的内容。

Answer 2

只要你不是在同一时间传送对象的一个​​（即，不这样做the dumb way），客户端的fetch过程中使用的客户端和服务器之间的信息流连接，与the client sending with a series of "want/already-have"s as the server offers a series of "have"s，为了弄清楚什么客户需要的对象。然后，一旦对象达成一致，服务器将这些对象聚合成一个瘦身包。这个精简包是针对客户已知的对象进行增量压缩的。

对于非浅层存储库，服务器可以相信客户端不仅拥有被拒绝的对象，而且拥有所有的前置对象，因此即使是相当大的对象集也会生成很小的包文件（具体取决于什么前辈确实存在，并且服务器能够快速压缩这些对象）。例如，假设200个新的或更新的文件与200个以前的版本非常相似。这个瘦身包可能基本上由200套指令组成，这些指令说“复制旧的1234567...，然后在中间添加六个字节”而不是“这里是200千兆字节的原始数据”。

这种瘦身包需要花费大量的CPU时间才能生产，但只需几秒钟即可在最慢的环节中进行传输。

显然，如果200个新对象与任何以前的对象都不相似，也不会相互影响，增量压缩将无济于事。在这种情况下，瘦身包只会受益于zlib放气压缩产生的任何效果。

在任何情况下，提取客户端都会收到（单个）精简包文件，并通过从客户端已有的对象中添加缺失的基础，将其修复为非精简包。因此，作为T0xicCode answered，只有一个文件传输。