You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Git for Windows functionality breaks when repository is open in Remote WSL #903
I'm having a strange problem with WSL and using an external Git Client. When I open a project using WSL, I cannot switch branches using my external client (I'm using Gitkraken). I'm getting an 'Access denied'-Error on ./git/index.
I can switch branches in VS Code itself without problems. The thing is: After I switched branches in VS Code, I'm suddenly able to switch branches in my external Git client as well ... UNTIL I close VS Code and open it again, using WSL.
I haven't tried anything besides switching branches yet, afraid to break anything ;).
Steps to Reproduce:
Open a folder with VS Code & WSL which contains a Git Repository
Try switching your branch with another tool, i.e. Gitkraken or even try doing a "git checkout
This will result in something like this:
Rename from 'C:/<path_to_repo>/.git/index.lock' to 'C:/<path_to_repo>/.git/index' failed. Should I try again? (y/n) n
fatal: unable to write new index file
Reacted by Nicolas Delvat, Gaurav Hirlekar, rib2bit, Sandro Winkler, Brian Collum, edmundo096, MauroFVieira, Michael Flucher, Thomas Herbst, john doe and 18 more
I'm doing development for NodeJS, with our production server being based on Linux (while I am developing on Windows). I sometimes have problems with some libraries that need to be compiled first for the OS. Sometimes this is working on my development workstation, but not on the server and vice versa.
I thought I could work around this by developing / testing with WSL so I'm always working on the same fundament.
Reacted by Sandro Winkler, Michael Flucher, Jesse Niininen, Sebastian Duque Gutierrez, Ján Tančibok, Jason Forrestall, Jon Marsh and Kyrie
This doesn't reproduce it, which I think is strange. Maybe it's something about the size of the repository?
EDIT: Ah, I just reproduced it. My first test was actually using the WSL directly, not through VSCode and the remote development plugin.
I just opened the repo inside VSCode using the plugin, made one commit and as soon as I did that, I couldn't do a git checkout <branch> in windows anymore
The code is on the windows drive like D:\code\foo. And VSCode is opened in remote WSL mode, the root dir is /mnt/d/code/foo.
In this case, git running on the host can not checkout or stage or commit any code. The error is "Rename from 'D:/code/foo/.git/index.lock' to 'D:/code/foo/.git/index' failed. Should I try again? (y/n)"
After closing VSCode, git on windows works again.
Reacted by edmundo096, Jesse Niininen, Skyexu, Benjamin McIntire, Renaat De Muynck, Nathan Reed and 幽幽子
I just ran into this problem in WSL 1 and was able to resolve it simply by upgrading to WSL 2. Nothing else changed in my system so perhaps there is some side effect of upgrading that caused this to be resolved for me?
WSL1 and WSL2 are totally different implementations with totally different back ends. WSL2 has all sorts of other implications and impacts, so I view this suggestion as a workaround and not a fix.
Ubuntu 20.02 on WSL2
Windows 10 Pro, Build 19041.572
Accessing my repo from /mnt/c/GitHub/foo
Trying to commit from Github Desktop or Git CLI both report an issue.
Removing git from Ubuntu does not help. The only thing that unlocks the file is closing VSCode.
Does anyone have any fixes? I have not attempted the fix for excluding the git folder yet as I am under the impression that it only applies to WSL1. I prefer to mange my repo using Github Desktop on Windows.
It solved the problem to add the following in the settings.json: "remote.WSL.fileWatcher.polling": true, "files.watcherExclude": { "**/.git/**": true }
I'm also running into something like this with the following setup:
Running WSL 2 bash through ConEmu to perform git operations on a git repo
Editing files in ^git repo^ that are located outside of WSL using VSCode
After editing in VSCode, .lock files appear to persist in my .git/ folder
Committing and pushing works so long as I close VSCode, remove the lock files and then commit/push. If I leave VSCode open, the lock files reappear immediately and commit/push is blocked. I have not modified any Remote - WSL settings in VSCode.
WSL 2
Ubuntu 20.02
VSCode 1.15.1
Windows 10.0.19042
Edit: Intermittently fixed
Applying robross0606 's workaround by doing the following appears to have fixed it:
Enable Json settings editor (type workbench.settings.editor in preferences search and set it to json)
Close settings and re-open them (A JSON file should be opened now)
This is still a problem, almost two years later. I'm on WSL1, opening a VSCode workspace from WSL, and attempting to use Git Fork on Windows. Using the suggested "files.watcherExclude" settings seemed to fix the problem with not being able to stage or unstage files, but then I still had similar errors when trying to do a git fetch or pull. I ended up just adding "git.enabled": false in my workspace settings and leaving it at that.
BTW, even though there were some reports that this is solved by WSL2 (and some reports that it isn't), I don't want to upgrade to WSL2 at this time because of the warnings about reduced cross-file-system performance. Microsoft's own documentation recommends:
Consider using WSL 1 if:
A project which requires cross-compilation using both Windows and Linux tools on the same files.
File performance across the Windows and Linux operating systems is faster in WSL 1 than WSL 2, so if you are using Windows applications to access Linux files, you will currently achieve faster performance with WSL 1.
This is exactly my case: I am developing a cross-platform library and building both Windows and Linux versions out of the same repo. (I suppose I could check out a separate clone of the repo inside the Linux filesystem, but that seems like a lot of extra hassle.)
This problem occurs even with vscode closed. This has nothing to do with vscode at all. Mucking with git on WSL appears to irrevocably mess with permissions of the .git folder on Windows. I have been unable to fix the permissions at all.
Was there ever a solution to this? I don't see any resolution in the linked issues.
I found that the solution to this was permissions in WSL for the folder. I just had to take ownership of the folder and its subdirectories and this resolved the issue for me.
sudo chown -hR user:user ~/
This will give ownership to the home and subdirectories/files to user (your wsl username), and then this gave my GIT tools, including gitkraken access to the files as expected.
Reacted by Jacob Stanley, Valery Zinchenko and Actualization
Activity
joaomoreno commentedon Jul 8, 2019
Are the files inside WSL? Are you using git from within WSL?
dhebgen commentedon Jul 8, 2019
No, I'm using them from the outside.
joaomoreno commentedon Jul 8, 2019
Are the files inside WSL?
dhebgen commentedon Jul 8, 2019
Yes, the files are on my main Windows drive (C:\nodeWorkSpace\projectFolder) and are opened via VSCode using Remote-WSL.
joaomoreno commentedon Jul 8, 2019
There must be something about the way git inside WSL creates that index file that makes it that on the Windows side other tools can't access it.
One more question: if your files live outside WSL... why not simply using Code without WSL?
dhebgen commentedon Jul 8, 2019
I'm doing development for NodeJS, with our production server being based on Linux (while I am developing on Windows). I sometimes have problems with some libraries that need to be compiled first for the OS. Sometimes this is working on my development workstation, but not on the server and vice versa.
I thought I could work around this by developing / testing with WSL so I'm always working on the same fundament.
joaomoreno commentedon Jul 8, 2019
Makes sense. Can you try the following setup without VS Code:
cdinto a new folder inC:\nodeWorkSpaceand thengit initand add a few files/commitsgit checkoutDoes the same reproduce?
dhebgen commentedon Jul 8, 2019
This doesn't reproduce it, which I think is strange. Maybe it's something about the size of the repository?
EDIT: Ah, I just reproduced it. My first test was actually using the WSL directly, not through VSCode and the remote development plugin.
I just opened the repo inside VSCode using the plugin, made one commit and as soon as I did that, I couldn't do a
git checkout <branch>in windows anymorethe729 commentedon Jul 10, 2019
Same problem.
The code is on the windows drive like D:\code\foo. And VSCode is opened in remote WSL mode, the root dir is /mnt/d/code/foo.
In this case, git running on the host can not checkout or stage or commit any code. The error is "Rename from 'D:/code/foo/.git/index.lock' to 'D:/code/foo/.git/index' failed. Should I try again? (y/n)"
After closing VSCode, git on windows works again.
joaomoreno commentedon Jul 11, 2019
Dustin Hebgen (@dhebgen) Odd. VS Code will simply spawn WSL's git, so it's strange you can't reproduce this when using WSL git directly.
11 remaining items
jessehouwing commentedon Jun 17, 2020
I have outstanding pull Requests to the Powerlines I've been using:
https://github.com/jessehouwing?tab=repositories&q=powerline&type=&language=
Syriiin commentedon Oct 18, 2020
This issue appears to be resolved in WSL 2.
Upgrading should
fixworkaround it.https://docs.microsoft.com/en-us/windows/wsl/install-win10
jessehouwing commentedon Oct 18, 2020
Syriiin commentedon Oct 18, 2020
I just ran into this problem in WSL 1 and was able to resolve it simply by upgrading to WSL 2. Nothing else changed in my system so perhaps there is some side effect of upgrading that caused this to be resolved for me?
robross0606 commentedon Oct 18, 2020
WSL1 and WSL2 are totally different implementations with totally different back ends. WSL2 has all sorts of other implications and impacts, so I view this suggestion as a workaround and not a fix.
spaceneenja commentedon Oct 19, 2020
Also experiencing this issue.
Ubuntu 20.02 on WSL2
Windows 10 Pro, Build 19041.572
Accessing my repo from /mnt/c/GitHub/foo
Trying to commit from Github Desktop or Git CLI both report an issue.
Removing git from Ubuntu does not help. The only thing that unlocks the file is closing VSCode.
Does anyone have any fixes? I have not attempted the fix for excluding the git folder yet as I am under the impression that it only applies to WSL1. I prefer to mange my repo using Github Desktop on Windows.
msft-tacox commentedon Oct 26, 2020
When this issue is encountered, is there a way to fix?
laurelhillowl commentedon Nov 16, 2020
It solved the problem to add the following in the settings.json:
"remote.WSL.fileWatcher.polling": true, "files.watcherExclude": { "**/.git/**": true }makosblade commentedon Nov 16, 2020
I'm also running into something like this with the following setup:
After editing in VSCode,
.lockfiles appear to persist in my.git/folderCommitting and pushing works so long as I close VSCode, remove the lock files and then commit/push. If I leave VSCode open, the lock files reappear immediately and commit/push is blocked. I have not modified any Remote - WSL settings in VSCode.
Edit: Intermittently fixed
Applying robross0606 's workaround by doing the following appears to have fixed it:
workbench.settings.editorin preferences search and set it to json)This has decreased occurrences of the lock issue to ~20% of the time I do a commit instead of ~90% of the time
ComFreek commentedon Dec 3, 2020
All the previous suggestions didn't fix it for me. In the remote settings (JSON) I am now trying
Not field-tested yet. This completely deactivates Git integration — but I use Git from my console (on Windows, not WSL) anyway.
Reedbeta commentedon Jun 28, 2021
This is still a problem, almost two years later. I'm on WSL1, opening a VSCode workspace from WSL, and attempting to use Git Fork on Windows. Using the suggested "files.watcherExclude" settings seemed to fix the problem with not being able to stage or unstage files, but then I still had similar errors when trying to do a git fetch or pull. I ended up just adding
"git.enabled": falsein my workspace settings and leaving it at that.BTW, even though there were some reports that this is solved by WSL2 (and some reports that it isn't), I don't want to upgrade to WSL2 at this time because of the warnings about reduced cross-file-system performance. Microsoft's own documentation recommends:
This is exactly my case: I am developing a cross-platform library and building both Windows and Linux versions out of the same repo. (I suppose I could check out a separate clone of the repo inside the Linux filesystem, but that seems like a lot of extra hassle.)
jtstanley commentedon Jan 18, 2022
robross0606 I'm having the same difficulty as you on WSL2 (i.e. with only WSL and Git, independent of VS Code):
#903 (comment)
Was there ever a solution to this? I don't see any resolution in the linked issues.
scoussens commentedon Feb 3, 2022
Jacob Stanley (@jtstanley)
I found that the solution to this was permissions in WSL for the folder. I just had to take ownership of the folder and its subdirectories and this resolved the issue for me.
sudo chown -hR user:user ~/
This will give ownership to the home and subdirectories/files to user (your wsl username), and then this gave my GIT tools, including gitkraken access to the files as expected.