Git 如何从 UNC 路径中获取更改？

Question

我在 Windows PC 上的共享文件夹中有一个 Git 存储库，我正在使用 UNC 路径访问它，例如

git clone //server/share/MyRepo.git

当我在家中通过 VPN 从该存储库获取更改时，git-upload-pack.exe 需要 非常 很长时间才能运行。我意识到没有服务器（本身）涉及，我的本地 PC 正在运行所有可执行文件。

git-upload-pack.exe 的名称向我暗示，我的本地 PC 正在从远程文件共享中读取文件，以便将它们上传到某处，但那将是它自己，这没有任何意义。这反过来又让我认为fetch 的性能远不及它所能达到的水平。这就像本地机器正在做所有的工作来减少要传输的数据，但要做到这一点，它必须传输所有的数据。

谁能解释一下这是如何工作的？在不通过 SSH 或其他任何方式在远程端运行真正的 Git 服务器的情况下，性能是否尽可能好，或者文件是否不必要地来回传输？

Answer 1

使用 git 2.1（2014 年 8 月），这个获取应该更快：一个旧的 2012 修复最终被集成到 git 中。

见commit 76e7c8a(theoleblond)

compat/poll: 休眠 1 毫秒以避免忙等待

SwitchToThread() 只将当前时间片的剩余部分交给当前进程中的另一个线程。因此，如果提供我们正在轮询的文件描述符的线程不在当前进程中，我们就会忙于等待。

我玩了很多次。在尝试了一些更复杂的方案后，我发现最好的方法是在迭代之间只休眠 1 毫秒。虽然时间很短，但还是完全消除了忙等待的情况，不影响性能。

那里的代码使用SleepEx(1, TRUE)来休眠。
请参阅this page，详细讨论为什么这比调用SwitchToThread 更好，这是以前使用的：

请注意，调用 SleepEx(0, TRUE) 并不解决繁忙的等待。

最引人注目的案例是在单个 CPU 机器上测试具有大型 repo 的 UNC 共享。
如果没有修复，它需要 4 分 15 秒，而修复它只需要 1:08！我认为这是因为git-upload-pack 的忙碌等待正在从执行实际工作的 git 进程中占用 CPU。
使用 multi-proc，时间并没有太大的不同，但是仍然浪费了大量的 CPU 时间，这对于需要做很多其他事情的服务器来说可能是一个杀手。

Answer 2

它认为它就像本地文件系统。

有 git over SSH 的替代方案：

1. HTTP[S] (git-http-backend)
2. 普通的 git 守护进程。