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 中。

请参阅( theoleblond )提交的 76e7c8a

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

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

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

那里的代码使用SleepEx(1, TRUE)来睡眠。
请参阅此页面，了解为什么这比调用SwitchToThread更好，这是以前使用的方法：

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

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

Answer 2

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

git 有替代 SSH 的替代品：

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