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

Question

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

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 字节）
• 如果我在 git 解包时附加 ProcMon 并断开连接，该过程仍然失败，通常是在不同的对象上。
• 根据目标位置，同事也会经历相同的成功/失败模式。
• 如果我从本地目录执行 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

这就是“ promissor remote ”的概念出现的地方。

该概念与transfer.fsckobjects配置一起使用：它告诉“ git fetch ”验证接收到的包中对象的数据和连接性； 执行此检查的代码已被教导关于窄克隆的约定，即丢失可从来自promissor 遥控器的包中的对象访问的对象是可以的。

在 Git 2.29（2020 年第 4 季度）之前，虽然将许多对象打包到一个具有承诺者远程的存储库中，但从承诺者远程一个接一个地懒惰地获取丢失的对象可能效率低下。

代码现在尝试批量获取所有丢失的对象（显然这不适用于懒惰地获取树对象的懒惰克隆，因为在您了解丢失了哪些树之前，您甚至无法枚举丢失的 blob）。

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

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

pack-objects : 预取要打包的对象

^{签字人：Jonathan Tan}

当发现某个待打包对象丢失时，一次性预取所有待打包对象。

---

在 Git 2.29（2020 年第 4 季度）中，当使用 packfile URI 功能时，“ git fetch ” ^{( man )}效果更好。

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

fetch-pack ：使fetch-pack文件 URI 与transfer.fsckobjects

^{签字人：Jonathan Tan}

当使用 packfile URI 和transfer.fsckobjects=1获取时，在调用index-pack时使用--fsck-objects而不是--strict标志，以便不检查链接，只检查对象。

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

这类似于98a2ea46c2 （“ fetch-pack : do not check links for partial fetch”, 2018-03-15, Git v2.17.0-rc1 -- merge ），但用于包文件 URI 而不是部分克隆。

---

在 Git 2.31（2021 年第一季度）中，我们对使用 packfile URI 功能下载的包文件有了更多了解。

请参阅Jonathan Tan ( jhowtan ) 提交的 bfc2a36 (20 Jan 2021 ) 。
^{（由Junio C gitster合并-- gitster -- in commit d03553e ，2021 年 2 月 3 日）}

Doc ：阐明作为 URI 发送的包Doc内容

^{签字人：Jonathan Tan}

澄清一下，当使用 packfile-uri 功能时，客户端不应假设下载的额外包文件仅包含单个 blob，而是支持包含所有类型的多个对象的包文件。

technical/packfile-uri现在包含在其手册页中：

blob 被排除在外，替换为 URI。 正如下面的“未来工作”中所述，服务器可以在未来发展以支持排除其他对象（或者可以制作支持排除其他对象的其他服务器实现），而无需更改协议，因此客户端不应期望下载的包文件以这种方式只包含单个 blob。

---

在 Git 2.33（2021 年第三季度）中，packfile-uri（用于获取，包括 OP 中的网络驱动器路径）的uploadpack.blobPackfileUri的描述得到了增强：

参见Teng Long ( dyrone ) 的commit 3127ff9 (13 May 2021 ) 。
^{（由Junio C gitster合并-- gitster -- in commit 8e1d2fc ，2021 年 6 月 10 日）}

packfile-uri.txt : 修复 blobPackfileUri 描述

^{签字人：腾龙
审核人：Jonathan Tan}

修复 packfile-uri.txt 中的 'uploadpack.blobPackfileUri' 描述，在 t5702 中也可以看到正确的格式。

technical/packfile-uri现在包含在其手册页中：

服务器由一个或多个uploadpack.blobPackfileUri= <object-hash> <pack-hash> <uri>条目配置。

每当组装要发送的对象列表时，所有此类 blob 都会被排除，并替换为 URI。

正如下面的“未来工作”中所述，服务器可以在未来发展以支持排除其他对象（或可以支持排除其他对象的其他服务器实现），而无需更改协议，因此客户端不应期望下载的包文件以这种方式只包含单个 blob。