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

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

git clone //server/share/MyRepo.git

当我从家里通过VPN从该存储库获取更改时，

git upload pack.exe

需要很长时间才能运行。我意识到没有涉及任何服务器，我的本地PC正在运行所有的可执行文件

git upload pack.exe的名称告诉我，我的本地电脑正在从远程文件共享读取文件，以便将它们上传到某个地方，但这是它自己的，这毫无意义。这反过来又让我想到，

获取

的性能远远没有达到它所能达到的水平。就像本地机器正在做所有的工作来减少要传输的数据，但要做到这一点，它必须传输所有的数据

---

有人能解释一下这是怎么回事吗？在不通过SSH或其他方式在远程端运行真正的Git服务器的情况下，性能是否尽可能好，或者文件是否被不必要地来回传输？

它认为它类似于本地文件系统

除了git over SSH之外，还有其他选择：

HTTP[S]（git HTTP后端）

普通git守护进程

有了Git2.1（2014年8月），这个获取应该快得多：一个旧的2012修复程序终于被集成到git中了

看管

compat/poll

：睡眠1毫秒以避免繁忙等待

SwitchToThread（）

只将当前时间片的其余部分提供给当前进程中的另一个线程。因此，如果为我们正在轮询的文件decscriptor提供数据的线程不在当前进程中，我们就会忙着等待

我经常玩这个。在尝试了一些更复杂的方案后，我发现最有效的方法是在迭代之间只睡1毫秒。虽然这是一个非常短的时间，它仍然完全消除了繁忙的等待条件，而不会影响性能

这些代码使用

SleepEx（1，TRUE）

进行睡眠。
有关为什么这比调用以前使用的

SwitchToThread

更好的详细讨论，请参阅：

请注意，调用

SleepEx（0，TRUE）

并不能解决繁忙等待问题

最引人注目的案例是在单CPU机器上测试具有大型回购协议的UNC共享。
没有修复，只需4分15秒，修复只需1:08！我认为这是因为git upload pack的繁忙等待消耗了git进程的CPU，而git进程正在进行真正的工作。
使用multi-proc时，时间差别不大，但仍然浪费了大量的CPU时间，这可能会成为服务器上需要做大量其他事情的杀手

---

在UNC访问场景中，一个旧补丁应该会使当前的git 2.0.x更快：see看起来像罪魁祸首！谢谢：）@GraemeF。该提交已在Git2.1中正式交付。我正在等待msysgit发布他们的2.1版“git for Windows”来测试它（）。正在进行：