Albeit very slowly. Unless they fixed it recently, writing to a vast amount of files is very slow compared to native Linux. Anyone who has cloned a large repository I'm sure is aware of this.

I felt like file speed sped up quite a bit in the Fall Creators Update, though of course that notion is entirely anecdotal.

Also, the native Windows git is still your best bet for git operations. That's one of the cases where I will have a PowerShell and an Ubuntu bash window side-by-side, working in the same /mnt/d/... | D:\... directory. git operations in PowerShell and Jekyll (or whatever) operations in Ubuntu bash.

Does it make a difference if you run your git operations through cmd from the bash command line? If so, is there a simple way to automatically get the current windows path from pwd? If it's the same speed as native git running in a separate window (I think it should be), it might be worth coming up with some kind of script to do this automatically. Not sure how to get that working with using Linux tools within git, though (editing commit messages, diffing, etc). Also, how does file speed within the Linux environment (/home/username) compare to that outside (/mnt/C/whatever)?

Also, they _really_ chose a poor name for that executable; it should have been wsl.exe or some such, not bash.exe. At least lxss.exe isn't already in use by other software in my path...

We just released a tool to do the right path translation -- wslpath. Unfortunately we haven't added built in usage info yet. Here's a link[1] to usage info in recent Windows Insider flights.

Also, totally fair feedback about the naming. In FCU, we added wsl.exe in addition to bash.exe. It launches into your default shell rather than /bin/bash.

[1] https://github.com/Microsoft/WSL/issues/2715

* I work at Microsoft on WSL

I hadn't thought about that (I use PowerShell for most tasks so that is still my "home" shell and it's bash that's the rare one), but I half remembered something to that effect, so I went to the docs:

https://docs.microsoft.com/en-us/windows/wsl/interop

Calling Windows EXEs from bash will automatically retain the current working directory under /mnt/c/*, so it should just work out of the box. Looks like you might be able to get away with just adding native Windows git to your bash path.

Yeah for example I have composer only installed in Windows (EXE) and not within WSL and it works fine within the bash prompt.