git status is slow in WSL2

[tuananh]

Please fill out the below information:

• Your Windows build number: 18956

• What you're doing and what's happening: type git status

• What's wrong / what should be happening instead:

very slow. time git status gives me

On branch develop
Your branch is up to date with 'origin/develop'.
nothing to commit, working tree clean
real    0m2.210s
user    0m0.000s
sys     0m0.452s

Note that this is quite small project.

[therealkenc]

On /mnt I presume. #4197

[tuananh]

Yes. I noticed it shortly after I opened this issue.

…

On Mon, Aug 12, 2019 at 3:28 PM therealkenc ***@***.***> wrote: On /mnt I presume. #4197 <#4197> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4401?email_source=notifications&email_token=AAEZETSH7ZKLOZ4S6NG4I6DQEENJFA5CNFSM4IK5XT22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4B3VWY#issuecomment-520338139>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEZETSY5ZCKEF3PWQZVKUTQEENJFANCNFSM4IK5XT2Q> .

[binarynate]

I appreciate Microsoft's work on WSL and will stick with WSL 1 until the the performance issues with accessing the Windows filesystem from WSL2 are worked out. I'm surprised that I didn't hear about this limitation ahead of time, though. The discussions I heard regarding WSL2 (like during this year's Build talks) focused on its performance improvements, so I was surprised by the significant downgrade in performance. In my case, I use WSL to interact with Unity projects targeting Windows, so using the Linux filesystem doesn't seem to be an option.

[0x49D1]

Same here and not only git status: Angular development just can't be continued; ng serve just does nothing. Other then /mnt performance - WSL2 seems OK (yes there are still high memory usage issues, but that's OK, compared to performance). And I can't migrate all my work (with .NET projects mixed with web ones) to Linux file system, so performance of /mnt fs is critical. Hope you can deal with this issue sooner or later, but it seems that more then a year of development did not overcome this problem, so probably it's very difficult to solve.

[TylerReid]

I came up with a dumb but useful workaround for this specific case. It works because windows git is faster against ntfs and I don't need any linux specific things for git at least.

I put this in my bash .profile

# checks to see if we are in a windows or linux dir
function isWinDir {
  case $PWD/ in
    /mnt/*) return $(true);;
    *) return $(false);;
  esac
}
# wrap the git command to either run windows git or linux
function git {
  if isWinDir
  then
    git.exe "$@"
  else
    /usr/bin/git "$@"
  fi
}

[bhechinger]

I came up with a dumb but useful workaround for this specific case. It works because windows git is faster against ntfs and I don't need any linux specific things for git at least.

@TylerReid This doesn't solve the issues with WSL2 obviously, but this addresses my biggest issue with WSL2 at the moment. THANK YOU SO MUCH!

[MolloKhan]

We can't leave comments anymore in the initial issue. I discovered that GIT runs not that slow when the project is small, like 2-3 seconds slower than it should be (annoying but manageable)
Another thing that I discovered is if you run GIT commands through PHPStorm's terminal it runs fast! I was expecting it to run slow as well but it does not. Perhaps this is not important but just in case. I hope this issue gets fixed soon because I really want to work with WSL2

[brentsony]

Why was this issue closed? It is still a super annoying issue (30+ seconds to return a git status or log).

One issue with the above fix, is that using git.exe is super fast (like using git in WSL1), it doesn't run the aliases you've defined in your home directory with something like git s or git l. Defining a function for each one is a workaround:

# wrap the git command to either run windows git or linux
function gits {
  if isWinDir
  then
    git.exe status -s --branch "$@"
  else
    /usr/bin/git "$@"
  fi
}
function gitl {
  if isWinDir
  then
          git.exe log -n15 --graph --abbrev-commit --date=relative --pretty='%Cred%an%Creset %w(110,0,7)%C(yellow)%d%Creset %s %Cgreen(%cr)%Creset %h' "$@"
  else
    /usr/bin/git "$@"
  fi
}

[iTaybb]

Please open this issue. This is still relevant.

[MolloKhan]

Agree

[calra123]

yes, the issue is still relevant.

[danrozenberg]

Also seeing this...

git status on WSL2 running Ubuntu-20.04 and git version 2.25.1 takes:

real    0m1.023s
user    0m0.109s
sys     0m1.016s

meanwhile, using Git Bash with the same repository, and git version 2.29.2.windows.2 it takes:

real    0m0.285s
user    0m0.000s
sys     0m0.015s

[MolloKhan]

It feels like asking for a feature fix in a source code project but the last time I checked Windows 10 Pro costs $200 dlls

[kenny1983]

LOL you are all lucky compared to me; git status for me (on a fairly large project) takes:

real    0m25.988s
user    0m0.599s
sys     0m9.483s

And initially cloning the project took about 1/2 an hour, whereas it would've taken a minute or two on Linux.

This is incredibly frustrating since the whole point of having WSL (for me at least) was to do all my software dev in that environment. As such, the "use Windows git instead" workaround mentioned by others is not viable for me.

I hate having two separate dev environments unless it's absolutely necessary, and to me, having to install Git for Windows just so I can run some simple commands that take less than half a second in Linux is ridiculous.

[bhechinger]

@kenny1983 I was really hoping WSL2 was going to be a lot better but this is such a killer thing. Check out multipass as a WSL alternative. Not as tightly integrated but worked pretty well before I just completely gave up and went back to Linux.

[aleen42]

I have considered using git.exe instead of /usr/bin/git, but it is not convenient for many reasons:

1. Unicode Text Encoding like Chinese
2. Worktree path needs to obey the convention under Windows

The best solution is to upgrade Git for performance enhancement

[onetdev]

If you are using zsh or any other shell with git reporting, you will struggle a lot because it will get the status of your repo anytime you do basically anything in your git project. Since probably most of us are using Docker + WSL2 together, going back to WSL1 is not really an option at this point.

So: I've just moved all my project into WSL itself (~/projects/whatever) without using the mounted local fs and it works like charm. You will probably need to fiddle with git over SSH (or just go with HTTPS) but other than that, great stuff.

Also you can access your WSL2 FS through \\wsl$ from file explorer, the new VSC even has WSL project open. Happy coding my friends.

[golkedj]

@orosznyet I have this exact same setup and I'm still seeing extremely slow git operations. My repository is within ~/some-directory but I've been waiting on a clone operation for more than 15 minutes. I'm really not sure what to do at this point

[onetdev]

@golkedj I understand your frustration. I've been there.
Shallow cloning (git clone <url> --depth=1) probably helps with cloning a repo but if git is slow in general I would check resource monitor (CPU + SSD load) to eliminate/find possible resource bottlenecks.

I tried having the working directory within WSL on multiple systems and it usually solved the problem but you probably need a different solution/workaround. WSL also has its own config, you might find something related there: https://docs.microsoft.com/en-us/windows/wsl/wsl-config#wsl-2-settings

[brentsony]

Same here. 50x slower in WSL2 compared to WSL1. Unusable.

[golkedj]

@orosznyet I have done some more testing on this. This issue is is the worst when running git operations on repositories that are located on Gitlab (all repositories, private, public, etc). When interacting with Gitlab I see speeds <= ~80 KiB/s. When checking out from Github I see speeds >= 1 MiB/s. When interacting with either Gitlab or Github using windows git.exe commands I see speeds >= 20 MiB/s. I have also ran a speed test on my WSL2 Ubuntu instance via the command line tool and am getting ~200 Mbpsdownload and~20 Mbpsupload. Furthermore, all of my repositories are within\wsl$\Ubuntu\home\golkedj` and therefore should not be experiences I/O performance issues based on what I have read in this thread and other threads.
I am convinced that this issue only recently starting presenting itself because I have been interacting with this repository for several months with this exact same WSL2 Ubuntu instance and have noticed no issues at all until recently when I was unable to do anything with this repository within a reasonable amount of time. For example when I first set up this WSL2 Ubuntu instance I cloned this repository without issue, but now a fresh clone of it is taking several hours to complete (I have not actually been able to wait long enough for it to complete successfully).

I am currently working around this issue by using wsl.exe after modifying the core.autocrlf setting to input but this is not ideal and I would really like some feedback on theories for why this issue only recently started presenting itself to me

Performance details:

• Gitlab clone with WSL Ubuntu's git command:
  • Receiving objects: 16% (553/3435), 268.01 KiB | 34.00 KiB/s
• Github clone with WSL Ubuntu's git command:
  • Receiving objects: 100% (1034/1034), 487.62 KiB | 4.31 MiB/s, done.
• speed test results: https://www.speedtest.net/result/c/1b45ae1f-41ba-4e32-bea2-bc283632ccdf
• Gitlab clone with Windows git.exe command:
  • Receiving objects: 100% (3435/3435), 903.49 MiB | 19.56 MiB/s, done.
• Github clone with Windows git.exe command:
  • Receiving objects: 100% (434/434), 7.43 MiB | 13.19 MiB/s, done.

[gabrieljoelc]

it might have stayed closed because it's kind of a dup with the currently open #4197

[UnsolvedCypher]

A temporary workaround is to replace the git Linux binary with a symbolic link to git.exe. I was able to run
sudo ln -s "/mnt/c/Program Files/git/mingw64/libexec/git-core/git.exe" git

in /usr/bin and now in addition to git commands, my zsh git reporting also works fast.

[aleen42]

@UnsolvedCypher You can directly alias it in .bash_aliases:

alias git="git.exe"

[banjo]

I have disabled /mnt/ from my WSL path using the wsl.conf file. For those that have done that you could do like this instead:

function isWsl {
    if [[ "$(</proc/sys/kernel/osrelease)" == *microsoft* ]]; then
        return true
    fi

    return false
}

function git {
    if isWsl; then
        git.exe "$@"
    else
        /usr/bin/git "$@"
    fi
}

This will run git.exe on all paths, not only Windows paths.

[maor-rozenfeld]

Can confirm that the easiest workaround to get git fast again is to install git for windows and add an alias in your WSL2 to git.exe

alias git="/mnt/c/Program\ Files/Git/bin/git.exe"

I just tried that now and git is lightning fast, but there might be side effects I'm not aware of yet.

[aleen42]

@maor-rosenfeld One of the side effects is that worktrees' path will be constructed as Window style paths, which won't be well recognized.

gitdir: C:/project/.git/worktrees/tree1 # generated by git.exe
gitdir: /mnt/c/project/.git/worktrees/tree1 # generated by Linux git

[maor-rozenfeld]

@maor-rosenfeld One of the side effects is that worktrees' path will be constructed as Window style paths, which won't be well recognized.

gitdir: C:/project/.git/worktrees/tree1 # generated by git.exe
gitdir: /mnt/c/project/.git/worktrees/tree1 # generated by Linux git

So this means you might not be able to go back to using linux git without re-cloning the repo?

[aleen42]

So this means you might not be able to go back to using linux git without re-cloning the repo?

@maor-rosenfeld It also means a compatibility problem when you maintaining a project in WSL (Linux git) and in IDEA (Windows git.exe) at the same time.

The workaround for me is to keep the project and worktree copies in the same driver, and modify the gitdir with a relative path:

gitdir: ../project/.git/worktrees/tree1

I have mentioned above: #4401 (comment)

[stefanmohl]

Using git.exe doesn't work for me. There are files in our git-repo that do not obey Windows file-name requirements (e.g. files with colon ":" in them), so I can't use a Windows-git.

[janegilring]

I have been using VS Code devcontainers based on Ubuntu 20.04 for a while, with mount points to the Windows file system via WSL2. It has been rather slow and sluggish with regards to Git operations, so I tried to look into it a bit today - ending up in this GitHub issue.

As I did not want to pursue the git.exe workaround due to the implications mentioned above, I rather looked at what version of the Git Linux binary I was using. 2.25.1 was bundled with Ubuntu 20.04.

I then found this article which states:

On an LTS system, the software stability is of upmost importance this is why Ubuntu 18.04 and other distributions often provide older but stable version of a software that is well tested with the distribution release.

Hence, I rebuilt my devcontainer, adding the following to my Dockerfile:

RUN apt install software-properties-common -y && add-apt-repository ppa:git-core/ppa -y && apt update && apt install git -y

After that, the Git version was updated to 2.32.0 - the latest stable.

I have not made any measurements of any sorts, but at least the interactive experience of using the Git integration in VS Code inside the devcontainer is now much more performant.

Hence, I wanted to bring it up as a suggestion for others.

[HoLengZai]

To complete @janegilring's comment
For WLS2 / Ubuntu 20.04 LTS, I did this:

#To add a new repo for apt update (can work with nano, vi.. you prefer editor). So I do not need to install 'software-properties-common' for add-apt-repository
sudo emacs /etc/apt/sources.list
# add the following line at the end (this repo, no issue on WSL2):
deb http://ppa.launchpad.net/git-core/ppa/ubuntu focal main

sudo apt update
#If after apt update, you get a complaint about The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 1234567890123456798 do:
curl -sL "http://keyserver.ubuntu.com/pks/lookup?op=get&search=0x__REPLACE_BY_PUBKEYVALUE__" | sudo apt-key add
#Example: curl -sL "http://keyserver.ubuntu.com/pks/lookup?op=get&search=0xA1715D88E1DF1F24" | sudo apt-key add
#So you replace __REPLACE_BY_PUBKEYVALUE__ by your PUBKEY value
sudo apt update
sudo apt install git
git --version

So I got git 2.32.0 version too but I didn't see a noticeable speed improvement

[elouanKeryell-Even]

I had the same problem: a slow (~12s) git repo located on /mnt/c (windows filesystem)

I just switched to cloning my repo directly on the WSL2 linux filesystem (\\wsl$\Ubuntu), and I now have blazing fast performances!

---

As a side-note:

it used to be heavily not-advised to access the WSL2 linux filesystem from windows, for example editing files with an IDE etc... This is because it would cause file corruption: see this official blog note

However, according to more recent updates mentionned in this official blog note from 2019, it now seems perfectly fine to do it

[SpiRaiL]

I came up with a dumb but useful workaround for this specific case. It works because windows git is faster against ntfs and I don't need any linux specific things for git at least.

I put this in my bash .profile

# checks to see if we are in a windows or linux dir
function isWinDir {
  case $PWD/ in
    /mnt/*) return $(true);;
    *) return $(false);;
  esac
}
# wrap the git command to either run windows git or linux
function git {
  if isWinDir
  then
    git.exe "$@"
  else
    /usr/bin/git "$@"
  fi
}

Thanks so much!

my only addition is that I use pwd -P (with backticks) instead of $PWD so that it resolves my symbolic links into windows.

[nelsonym]

If you are using an IDE that supports WSL 2 and git (using extensions or plug-ins) like Visual Studio Code do git tasks/command using that extension/plug-ins the performance is superb :-D

[vemonet]

Windows please stop hiding basic features that you can't solve. This issue should be open, it is still relevant to WSL2 users, and it is a major issue that prevent using Windows for development. Git is ubiquitous in development, windows should be able to handle it decently

The idea behind WSL2 is that Windows users could use Linux without too much hassle.

But right now it's harder to use WSL2 than Windows or Linux. Because users need to know all the mess you created between Windows and Linux

I remember 10 years ago watching the video with Microsoft presenting WSL1 and insisting this was not just a VM in Windows, but a full built in Linux. That was straight up a lie. 10 years later you guys still can't access the Windows filesystem from your cheap Ubuntu VM

[lucasmontec]

Git is still absurdly slow under WSL. There is no reason why this ticket should be closed. Reopen it and fix your stuff. Thanks. Sorry for the rudeness.

[benhillis]

The root of the issue (slow cross-os file system performance) is tracked elsewhere. This issue was closed because it is not specific to git.