当目标是网络驱动器时，git clone失败

Question

我在使用MINGW32 shell中的git在Windows上克隆git存储库时遇到问题。基本症状是，当目标位于我的本地磁盘上时，克隆此特定存储库可正常工作，但当克隆目标位于网络驱动器上时，相同的命令将失败。这是本地克隆命令（编辑了repo名称）：

drichards@LT-DR MINGW32 /c/temp
$ git clone -v --progress <repo> gitrepo
Cloning into 'gitrepo'...
POST git-upload-pack (250 bytes)
remote: Counting objects: 82, done.
remote: Compressing objects: 100% (71/71), done.
remote: Total 82 (delta 26), reused 0 (delta 0)
Unpacking objects: 100% (82/82), done.
Checking connectivity... done.

在网络驱动器上尝试完全相同的过程会导致失败。在这种情况下，驱动器S：映射到网络位置。

drichards@LT-DR MINGW32 /s/temp
$ git clone -v --progress <repo> gitrepo
Cloning into 'gitrepo'...
POST git-upload-pack (250 bytes)
remote: Counting objects: 82, done.
remote: Compressing objects: 100% (71/71), done.
fatal: failed to read object 9b081a422a5f7d06ff5a2cb4889d26b4f18c6181: Permission denied
fatal: unpack-objects failed

暂时创建文件夹'gitrepo'，然后在失败时清理，因此我无法轻易地通过它找出问题所在。这似乎是一个相当简单的权限问题，所以我认为附加ProcMon将是一个很好的解决方案，可以找出它出错的地方，但是，当ProcMon运行时，克隆没有问题。

这似乎意味着当目标是网络驱动器时会出现某种一致性问题或竞争条件。当目标是GIT_TRACE设置为1并且ProcMon未连接的网络驱动器时，我收集了输出 - 这并没有显示我眼中有趣的东西。这是失败的时刻：

11:07:48.262535 run-command.c:336       trace: run_command: 'unpack-objects' '--pack_header=2,82'
11:07:48.324578 git.c:350               trace: built-in: git 'unpack-objects' '--pack_header=2,82'
fatal: failed to read object 9b081a422a5f7d06ff5a2cb4889d26b4f18c6181: Permission denied
fatal: unpack-objects failed

我还尝试通过添加git clone -c transfer.fsckObjects=1来请求git验证对象，但这不会改变症状。

如前所述，问题似乎特定于存储库。以下是其他一些数据点：

• 代码托管服务器（与目前为止提到的所有其他机器分开）有许多存储库，我已将其他几个克隆到网络上，没有任何问题。
• 无论是否进行常规克隆或裸克隆，都会出现此问题
• 导致失败的对象似乎没有什么特别之处（打包大小是中间的 - 727字​​节）
• 如果我附加了ProcMon并在git解包时断开连接，则该过程仍会失败，通常是在另一个对象上。
• 同事也会遇到相同的成功/失败模式，具体取决于目的地位置。
• 如果我从本地目录执行git，将目标目录指定为UNC路径，则进程仍然失败

以下是我本地计算机上的一些重要统计信息：

$ systeminfo
<snip>
OS Name:                   Microsoft Windows 8.1 Pro
OS Version:                6.3.9600 N/A Build 9600
<snip>
$ uname -a
MINGW32_NT-6.3-WOW LT-DR 2.5.0(0.295/5/3) 2016-03-31 18:26 i686 Msys
$ git --version
git version 2.8.3.windows.1

托管目标目录的服务器运行Windows Server 2008.代码服务器正在运行gitlab-ce 8.9.3。

Answer 1

这里是“ 远程遥控”概念的出现。

该概念与transfer.fsckobjects配置一起使用：它告诉“ git fetch”验证接收到的数据包中对象的数据和连接性；已经执行了执行此检查的代码，了解了狭窄克隆的约定，即从远程遥控器发出的数据包中的对象可以丢失的丢失对象是可以的。

在Git 2.29（2020年第4季度）之前，虽然将许多对象包装在带有Promissor远程的存储库中，但懒惰地从Promote远程逐个获取丢失的对象可能是低效率的。

代码现在尝试批量获取所有丢失的对象（显然，这对于懒惰的克隆懒惰地获取树对象是无效的，因为您甚至无法枚举丢失的斑点，直到您了解丢失的树）。 / p>

这可能有助于您从网络驱动器克隆git。

请参见commit e00549a的commit 8d5cf95，Jonathan Tan (jhowtan)（2020年7月20日）。
^{（由Junio C Hamano -- gitster --在commit 5c454b3中合并，2020年8月4日）}

pack-objects：预提取要打包的对象

^{签名人：Jonathan Tan}

当发现要打包的对象丢失时，请分批预取所有要打包的对象。

---

仍然使用Git 2.29（2020年第四季度），当使用packfile URI功能时，“ git fetch” ^（man）效果更好。

请参见commit 0bd96be的commit ece9aea，commit 42d418d，Jonathan Tan (jhowtan)（2020年8月17日）。
^{（由Junio C Hamano -- gitster --在commit bdccf5e中合并，2020年9月3日）}

fetch-pack：使packfile URI与transfer.fsckobjects一起使用

^{签名人：Jonathan Tan}

在使用包文件URI和transfer.fsckobjects=1进行提取时，调用--fsck-objects时，请使用--strict而不是index-pack标志，以便仅检查对象，而不检查链接。

这是因为期望链接不完整。 （无论是否设置了transfer.fsckobjects，所有包下载完毕后，都将进行后续连接检查。）

这类似于98a2ea46c2（“ fetch-pack：请勿检查部分获取的链接”，2018-03-15，Git v2.17.0-rc1-merge），但是对于packfile URI而不是部分克隆。