WSL2 环境中的 git 推送在写入对象步骤期间挂起

Question

症状

我在 WSL2 环境中有一个 git 工作区。 工作区位于/mnt/c/workspace/repo下，从 Windows 通过路径C:\workspace\repo也可以看到。

当我在工作区中从 WSL2 侧执行 git 推送时，Git 会挂断此消息。

Enumerating objects: 39, done.
Counting objects: 100% (39/39), done.
Delta compression using up to 16 threads
Compressing objects: 100% (24/24), done.
Writing objects:  34% (9/26)

这是在此上下文中观察到的其他行为和环境信息。

• 我可以从 Windows 端与 git 一起推送这些文件，用于 windows 没有任何问题。
• 克隆文件后我可以推送几次。 在我的一些推送操作之后它不会工作。
• 此存储库仅包含文本文件。 整个存储库大小小于 1MB
• 我已经使用这个环境几个月了，但我只在这个存储库中观察到这个问题
• 当我将整个文件夹复制到不直接暴露给 Windows 的 ~/workspace/repo 时，也会发生此问题。
• 遥控器配置为连接 SSH 并使用 /home/<username>/.ssh 下的密钥

环境信息

• WSL 中的 Linux 图像：20.04.2 LTS（Focal Fossa）
• Git 版本：2.25.1
• Windows 版本：微软 Windows [版本 10.0.19042.844]

$ git config --global --list
user.email=<my mail address>
user.name=<my name>
http.postbuffer=524288000

尝试过的解决方法

配置 http.postBuffer

git config --global http.postBuffer 524288000

我在stackoverflow的不同问题中遵循了这个答案。 https://stackoverflow.com/a/26663047/3200358

这种解决方法对我不起作用。

Windows 权限变更属性 -r +s

我已经按照这个解决方法来修复 Windows 端的一些权限问题。 https://stackoverflow.com/a/63483040/3200358

attrib -r +s C:\workspace\repo

这种解决方法对我不起作用。

试过 sudo git push

我试过 sudo git push 以防 git 命令无法访问某些锁定文件。

sudo GIT_SSH_COMMAND='ssh -i /home/<username>/.ssh/id_rsa' git push origin master

这种解决方法对我不起作用。

使用https推

错误消息已更改。 但是这种解决方法对我不起作用。

$ git push --set-upstream origin master -vvvv
Pushing to https://github.com/kyasbal-1994/<repo-name>.git
Enumerating objects: 39, done.
Counting objects: 100% (39/39), done.
Delta compression using up to 16 threads
Compressing objects: 100% (24/24), done.
Writing objects: 100% (26/26), 5.53 MiB | 7.42 MiB/s, done.
Total 26 (delta 6), reused 0 (delta 0)
POST git-receive-pack (5802813 bytes)
error: RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanly: CANCEL (err 8)
fatal: the remote end hung up unexpectedly
fatal: the remote end hung up unexpectedly
Everything up-to-date

Answer 1

您是否尝试过使用 Windows git.exe git 实际上，您可以在.bashrc中设置别名：

alias wgit='/mnt/c/path\ to\ git/Git/git.exe`

This way, you have a Windows executable dealing with Windows files instead of a Linux executable dealing with Windows files, though I'm a little fuzzy on how things work with the mounting.

但是，我不确定输入路径时这可能对用户有多友好。

假设可行，甚至可能有一种方法可以在 bash 中编写智能包装器 function 来检测存储库所在的文件系统并调用正确的 ZBA9F11ECC3497D9993B933FDC2BD6...

作为替代方案，您可能会更幸运地维护 2 个独立的存储库（WSL 和 Windows），然后通过服务器的推/拉同步。