Git 无法从 ownCloud 的 WebDAV 接口克隆仓库。

Question

我在ownCloud上拥有一些个人的git存储库。通过访问ownCloud的webdav url：http://myserver.a/remote.php/webdav/repos/repo.git，我可以在2台Ubuntu机器和一台Windows PC上克隆它。

最近，我安装了带有git版本1.8.1.5的Arch Linux并出现了以下错误信息： fatal: http://myserver.a/remote.php/webdav/repos/repo.git/info/refs?service=git-upload-pack not found: did you run git update-server-info on the server?

我确实添加了post-update hook，在我的其他计算机上它最终可以使用。 服务器的error.log显示当git请求...info/refs?service...时，发生了404错误。

Ubuntu的git 1.7从服务器请求相同的url。但是，在收到错误代码404之后，它会请求.../info/refs HTTP/1.1，并成功返回代码200。

那么，为什么新版本的git失败了，我该如何解决？

- namnor

---

你解决了这个问题吗？我现在确实遇到了完全相同的问题。 - mincos

不幸的是，我没有。相反，我现在通过Apache Web服务器上的标准WebDAV文件夹托管我的git存储库。 - namnor

Answer 1

整个 ?service=... 事情是在1.6.6版本引入的git智能HTTP支持。与传统的HTTP支持相比，它更加高效，但需要在Web服务器上运行特殊的CGI二进制文件，并且不支持WebDAV。

在任何非错误的WebDAV实现中，它应该被忽略，但显然ownCloud认为它是文件名的一部分或其他原因，从而产生错误。可能有必要与ownCloud开发人员讨论这个问题。

在旧版本中，git退回到没有后缀的URL，但这也存在自己的问题。因此，第二个请求在1.8.0版本中被删除，并引入了一个新选项，可以关闭智能HTTP并直接使用旧的URL（这应该能够解决问题）。例如，它的用法如下：

GIT_SMART_HTTP=0 git fetch

如果您不想使用智能HTTP（但请注意，它在Github和其他合理的托管站点上可以正常工作，并且在那里推送不起作用），您可以在shell配置文件中导出该环境变量。

有关更改的详细信息，请参见https://git.kernel.org/cgit/git/git.git/commit/?id=02572c2e3afcc200936260f48863447726212a7c。

- Jan Krüger

---

同时，我已经听说了这个变化，但是你的解释真的很有帮助，谢谢！ - namnor

Answer 2

最近我遇到了将我的Git存储库推送到Nextcloud的相同问题。我检查了存储库的内容，发现那里没有info/refs文件。

研究后我找到了这个帖子：无法通过http克隆git仓库；找不到info/refs

在存储库基本目录中执行建议的命令git update-server-info创建了缺失的文件，我不再收到404错误。所以这里并不是查询字符串的问题。

不幸的是，我又遇到了另一个错误（“错误：...上没有DAV锁定支持”），这里有文档https://help.nextcloud.com/t/webdav-lock-on-file-doesnt-work/21451（附有指向Nextcloud项目的github问题链接）。

遗憾的是，目前还没有在Nextcloud上使用WebDAV的Git存储库。

- bug.spencor

Answer 3

这可能更加可靠了："git clone"^(man)从SHA256存储库中克隆使用SHA-1作为默认哈希算法的Git，并通过愚蠢的HTTP协议运行，没有正确设置生成的存储库，但这已在Git 2.32（2021年第二季度，8年后）得到纠正。

请参见 提交 00bc839（2021年5月11日）由Eric Wong（ele828）提交。
^{（由Junio C Hamano -- gitster --在提交 bdff041中合并，于2021年5月20日）}

remote-curl：修复对sha256仓库的克隆

^{签名-by：Eric Wong
Acked-by：brian m. carlson}

The remote-https process needs to update it's own instance of the_repository, when it sees an HTTP(S) remote is using sha256.
Without this, parse_oid_hex() fails to handle sha256 OIDs when it's eventually called by parse_fetch().

Tested with:

git clone https://yhbt.net/sha256test.git
GIT_SMART_HTTP=0 git clone https://yhbt.net/sha256test.git
(plain http:// also works)

Cloning the URL via git:// required no changes

---

注意：自Git 2.41（2023年第二季度）起，文档对GIT_DEFAULT_HASH和“git clone”^(man)之间的交互存在误导，现已明确指出该变量应被命令忽略。

请查看提交 5f0e37b（2023年4月26日），由Junio C Hamano（gitster）提交。
^{（于2023年5月15日由Junio C Hamano -- gitster --在提交 b14a730中合并）}

文档：GIT_DEFAULT_HASH在“clone”期间将被忽略

“is currently ignored”这个措辞容易被误解为我们希望它被执行。请重新表述，以明确表示实验性变量将被忽略。

从长远来看，在允许增量/逐步迁移对象格式的情况下，即从SHA-1存储库克隆以创建SHA-256存储库（或反之亦然），并在它们之间获取和推送时会双向转换对象格式，很可能我们会教授一个新选项“--object-format”给“git clone”^(man)，以表示您将使用源默认使用的任何对象格式，但这次我告诉您在我们这边使用这种格式，并根据需要进行即时对象格式转换。

因此，即使发生了这样的扩展，使得我们需要有一种方法来创建使用与源存储库不同的对象格式的新存储库，也完全可以忽略此实验性变量的设置。

git现在在其man page中包含以下内容：

GIT_DEFAULT_HASH

当克隆时，此值将被忽略，并始终使用远程仓库的设置。默认值为"sha1"。

- VonC