1

Symptoms

I have a git workspace in WSL2 environment. The workspace is located under /mnt/c/workspace/repo where is also visible from Windows by the path C:\workspace\repo.

When I do git push from WSL2 side in the workspace, Git hang up with this message.

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)

This is the other observed behavior and environment information in this context.

  • I can push these files from Windows side with git for windows without any problems.
  • I can push several times just after cloning files. It won't work after some of my push operations.
  • This repository just contains text files. The entire repository size is less than 1MB
  • I've used this environment for several months but I observed this issue just only for this repository
  • This problem also happened when I copied entire folder to ~/workspace/repo where is not exposed to Windows directly.
  • The remote is configured to connect with SSH and use the key under /home/<username>/.ssh

Environment information

  • Linux image in WSL: 20.04.2 LTS (Focal Fossa)
  • Git version: 2.25.1
  • Windows version: Microsoft Windows [Version 10.0.19042.844]
$ git config --global --list
user.email=<my mail address>
user.name=<my name>
http.postbuffer=524288000

Tried workarounds

Configureing http.postBuffer

git config --global http.postBuffer 524288000

I've followed this answer in different question in stackoverflow. https://stackoverflow.com/a/26663047/3200358

This workaround won't work for me.

Windows permission change attrib -r +s

I've followed this workaround to fix some permission problem in Windows side. https://stackoverflow.com/a/63483040/3200358

attrib -r +s C:\workspace\repo

This workaround won't work for me.

Tried sudo git push

I've tried sudo git push for in case when git command can't access some lock files.

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

This workaround won't work for me.

Using https to push

The error message was changed. But this workaround won't work for me.

$ 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
kyasbal
  • 1,132
  • 3
  • 12
  • 27
  • How are you authenticating? Are you using the keys in `/home//.ssh` And/or are you using some sort of agent setup? – xdhmoore Feb 27 '21 at 09:45
  • Yes, the key is under there. – kyasbal Feb 27 '21 at 09:46
  • Based on the message you're getting with HTTPS, I suspect there's some sort of network problem, potentially a non-default antivirus or firewall, or a proxy or other middlebox. Are you using any of those things? – bk2204 Feb 27 '21 at 13:33
  • Thank you for your comment. I only enabled Windows Defender. I believe I didn't configure my ubuntu environment with some of weird network configurations. However, I will try it with disabling Windows Defender later. – kyasbal Feb 27 '21 at 14:19

1 Answers1

2

Have you tried invoking Windows' git from WSL by using the path to the Windows git.exe? In fact you could set up an alias in your .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.

However, I'm not sure how user-friendly this may be when entering paths.

Assuming that works, there's probably even a way to write a smart wrapper function in bash that detects which file system the repo is on and invokes the right git executable...

As an alternative, you may have more luck maintaining 2 separate repos (WSL & Windows) and then syncing via push/pulls from a server.

xdhmoore
  • 8,935
  • 11
  • 47
  • 90
  • 1
    Thank you for advising me this mitigation! This works for me enough. However, let me wait to select you as the best answer for a while because maybe someone come up with some actual cause of this. – kyasbal Feb 27 '21 at 14:21