4 ms·

> I guess there is some unfortunate reason why they can't do the same here Because they want to support Git for Windows which is built upon Cygwin/msys. And t

> I guess there is some unfortunate reason why they can't do the same here Because they want to support Git for Windows which is built upon Cygwin/msys. And this is fine because Cygwin is much faster than WSL and a good Windows integration is so much easier. Would be a total PITA if Git would only be available through WSL. Cygwin is still the best thing ever happened to Windows (or to Linuxers who are forced to work with Windows).

nsteel 3y ago
> Because they want to support Git for Windows which is built upon Cygwin/msys I read that, but I was wondering why they wanted that because they don't say. I've never noticed git to be slow under WSL but I guess that very much depends on your repo size and exactly what you are doing. It all sounds like a tremendous amount of hassle otherwise. I agree, Cygwin did enable us to work productively for many years. But Cygwin's drive mounting modes caused lots of pain. And the Xserver is simply awful. It is/was a constant source of issues, the worst being the incredibly frustrating crashes. Maybe they were due to underlying issues in the applications themselves but those apps work fine under WSLg (of course there are other bugs but we can still work with those).
- camtarn 3y ago
  Git is very slow under WSL2 when working with our medium-sized repos hosted on Windows filesystems (required by our Windows-only tooling). It's not unusable, but 'git status' under WSL1 was almost instant, whereas it takes a good few seconds under WSL2.
  - lathiat 3y ago
    It’s due to what is effectively a network file system. You have the same issue with nfs, 9pfs, parallels prl_fs, etc. It has to stat every file in the repo and that gets expensive on ang RPC protocol. Even local ones apparently. This is made worse because git uses the os-specific file statistics including inode number to track file changes. These change over most such file systems types which triggers it to rebuild the entire file cache every time you switch OS running git commands. Which if you have shell integration is constantly. I share my git repos between MacOS and a Linux volume and it hurts on any repo with 100s of thousands of files or more. Ceph, Linux kernel, etc.
    - nsteel 3y ago
      Turns out you guys are right. I tried a bigger repo and it was slow. I tried our large monorepo and it was utterly unusable (literally minutes for git status). I've found this thorough explanation https://github.com/microsoft/WSL/issues/4197#issuecomment-604592340 https://github.com/microsoft/WSL/issues/4197#issuecomment-60...
  - verall 3y ago
    I have git for windows installed and then alias git=git.exe so git from WSL just calls windows git which is much faster and I've never noticed any issues with this. I also use WSL1 though so maybe my setup is weird.
    - nsteel 3y ago
      The github link I posted elsewhere explains why WSL1 is far more performant, most don't need that hack in the WSL1 case (but doesn't hurt).
Borg3 3y ago
I damn agree. Especially older cygwin stuff is very very fast. I personally still use my own fork of cygwin-1.3 DLL for my old windoze. Works like a charm and I can use cool terminal (bash) with all CLI tools I love so much.
owl57 3y ago
> Cygwin is much faster than WSL Is it? I'm pretty sure WSL is much faster if your workflow allows putting files on Linux filesystem, but I also recall that perf in shared Windows folders felt about the same (bad, but not even worse) when I switched from msys git to WSL. But haven't used Windows in years, so memory could be bad.
- chasil 3y ago
  I have heard elsewhere that WSL is much faster with fork(). Cygwin is roughly 100x slower with forking than Linux on the same hardware. I understand that Postgres benefits greatly in running under the WSL for this reason.
alyandon 3y ago
Ironically, I still prefer using Cygwin to WSL despite the impedance mismatch with Windows. I really wish that Microsoft had been able to make WSL1 work better instead of giving up and going with the VM route with WSL2.
- whizzter 3y ago
  Manager prematurely distrusting developers syndrome, WSL1 had serious MMAP issues that was delayed as "low-prio" that wasn't fixed until late in the cycle (probably long after the decision to go with WSL2 was taken). Once those were fixed a ton of "weird" bugs magically got fixed. Sure WSL1 could never have handled docker as-is, but general software would've been mostly fine and given us damn good windows application integration. (And I'm sure some Docker shims would've appeared fairly quickly to satisfy most basic developer needs).
  - alyandon 3y ago
    Most likely - just like shims popped up to share PuTTY's ssh-agent with WSL1. These days I'm just running a full blown Linux DE in a VirtualBox VM since its graphic console isn't objectively terrible like Hyper-V. If for some reason I need to copy/sync files with the Windows host - well that's just an rsync away thanks to Cywgin.

nsteel 3y ago

> Because they want to support Git for Windows which is built upon Cygwin/msys I read that, but I was wondering why they wanted that because they don't say. I've never noticed git to be slow under WSL but I guess that very much depends on your repo size and exactly what you are doing. It all sounds like a tremendous amount of hassle otherwise. I agree, Cygwin did enable us to work productively for many years. But Cygwin's drive mounting modes caused lots of pain. And the Xserver is simply awful. It is/was a constant source of issues, the worst being the incredibly frustrating crashes. Maybe they were due to underlying issues in the applications themselves but those apps work fine under WSLg (of course there are other bugs but we can still work with those).

camtarn 3y ago
Git is very slow under WSL2 when working with our medium-sized repos hosted on Windows filesystems (required by our Windows-only tooling). It's not unusable, but 'git status' under WSL1 was almost instant, whereas it takes a good few seconds under WSL2.
- lathiat 3y ago
  It’s due to what is effectively a network file system. You have the same issue with nfs, 9pfs, parallels prl_fs, etc. It has to stat every file in the repo and that gets expensive on ang RPC protocol. Even local ones apparently. This is made worse because git uses the os-specific file statistics including inode number to track file changes. These change over most such file systems types which triggers it to rebuild the entire file cache every time you switch OS running git commands. Which if you have shell integration is constantly. I share my git repos between MacOS and a Linux volume and it hurts on any repo with 100s of thousands of files or more. Ceph, Linux kernel, etc.
  - nsteel 3y ago
    Turns out you guys are right. I tried a bigger repo and it was slow. I tried our large monorepo and it was utterly unusable (literally minutes for git status). I've found this thorough explanation https://github.com/microsoft/WSL/issues/4197#issuecomment-604592340 https://github.com/microsoft/WSL/issues/4197#issuecomment-60...
- verall 3y ago
  I have git for windows installed and then alias git=git.exe so git from WSL just calls windows git which is much faster and I've never noticed any issues with this. I also use WSL1 though so maybe my setup is weird.
  - nsteel 3y ago
    The github link I posted elsewhere explains why WSL1 is far more performant, most don't need that hack in the WSL1 case (but doesn't hurt).

Borg3 3y ago

I damn agree. Especially older cygwin stuff is very very fast. I personally still use my own fork of cygwin-1.3 DLL for my old windoze. Works like a charm and I can use cool terminal (bash) with all CLI tools I love so much.

owl57 3y ago

> Cygwin is much faster than WSL Is it? I'm pretty sure WSL is much faster if your workflow allows putting files on Linux filesystem, but I also recall that perf in shared Windows folders felt about the same (bad, but not even worse) when I switched from msys git to WSL. But haven't used Windows in years, so memory could be bad.

chasil 3y ago
I have heard elsewhere that WSL is much faster with fork(). Cygwin is roughly 100x slower with forking than Linux on the same hardware. I understand that Postgres benefits greatly in running under the WSL for this reason.

alyandon 3y ago

Ironically, I still prefer using Cygwin to WSL despite the impedance mismatch with Windows. I really wish that Microsoft had been able to make WSL1 work better instead of giving up and going with the VM route with WSL2.

whizzter 3y ago
Manager prematurely distrusting developers syndrome, WSL1 had serious MMAP issues that was delayed as "low-prio" that wasn't fixed until late in the cycle (probably long after the decision to go with WSL2 was taken). Once those were fixed a ton of "weird" bugs magically got fixed. Sure WSL1 could never have handled docker as-is, but general software would've been mostly fine and given us damn good windows application integration. (And I'm sure some Docker shims would've appeared fairly quickly to satisfy most basic developer needs).
- alyandon 3y ago
  Most likely - just like shims popped up to share PuTTY's ssh-agent with WSL1. These days I'm just running a full blown Linux DE in a VirtualBox VM since its graphic console isn't objectively terrible like Hyper-V. If for some reason I need to copy/sync files with the Windows host - well that's just an rsync away thanks to Cywgin.