Skip to content

Git for Windows functionality breaks when repository is open in Remote WSL #903

Open

Description

@dhebgen
  • VSCode Version: 1.36.0
  • Local OS Version: Windows 10 x64 Build 1903
  • Remote OS Version: Ubuntu 18.04.2 LTS
  • Remote Extension/Connection Type: WSL

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:

  1. Open a folder with VS Code & WSL which contains a Git Repository
  2. 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

Activity

  1. joaomoreno commented on Jul 8, 2019

    @joaomoreno

    external Git Client

    Are the files inside WSL? Are you using git from within WSL?

  2. dhebgen commented on Jul 8, 2019

    @dhebgen
    Author

    No, I'm using them from the outside.

  3. joaomoreno commented on Jul 8, 2019

    @joaomoreno

    Are the files inside WSL?

  4. dhebgen commented on Jul 8, 2019

    @dhebgen
    Author

    Yes, the files are on my main Windows drive (C:\nodeWorkSpace\projectFolder) and are opened via VSCode using Remote-WSL.

  5. joaomoreno commented on Jul 8, 2019

    @joaomoreno

    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?

  6. dhebgen commented on Jul 8, 2019

    @dhebgen
    Author

    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.

  7. joaomoreno commented on Jul 8, 2019

    @joaomoreno

    Makes sense. Can you try the following setup without VS Code:

    • In WSL, cd into a new folder in C:\nodeWorkSpace and then git init and add a few files/commits
    • In Windows, try git checkout

    Does the same reproduce?

  8. dhebgen commented on Jul 8, 2019

    @dhebgen
    Author

    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

  9. the729 commented on Jul 10, 2019

    @the729

    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.

  10. joaomoreno commented on Jul 11, 2019

    @joaomoreno

    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. added
    bugIssue identified by VS Code Team member as probable bug
    and removed
    info-neededIssue requires more information from poster
    on Jul 11, 2019
  12. 11 remaining items

  13. jessehouwing commented on Jun 17, 2020

    @jessehouwing

    I have outstanding pull Requests to the Powerlines I've been using:

    https://github.com/jessehouwing?tab=repositories&q=powerline&type=&language=

  14. Syriiin commented on Oct 18, 2020

    @Syriiin

    This issue appears to be resolved in WSL 2.
    Upgrading should fix workaround it.

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

  15. jessehouwing commented on Oct 18, 2020

    @jessehouwing
  16. Syriiin commented on Oct 18, 2020

    @Syriiin

    Ni, wsl2 does not fix it.

    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?

  17. robross0606 commented on Oct 18, 2020

    @robross0606

    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.

  18. spaceneenja commented on Oct 19, 2020

    @spaceneenja

    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.

  19. msft-tacox commented on Oct 26, 2020

    @msft-tacox

    When this issue is encountered, is there a way to fix?

  20. laurelhillowl commented on Nov 16, 2020

    @laurelhillowl

    It solved the problem to add the following in the settings.json:
    "remote.WSL.fileWatcher.polling": true, "files.watcherExclude": { "**/.git/**": true }

  21. makosblade commented on Nov 16, 2020

    @makosblade

    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)
    • Paste the aforementioned settings:
    "remote.WSL.fileWatcher.polling": true,
    "files.watcherExclude": {
        "**/.git/**": true
    }
    
    • Save and restart VSCode

    This has decreased occurrences of the lock issue to ~20% of the time I do a commit instead of ~90% of the time

  22. ComFreek commented on Dec 3, 2020

    @ComFreek

    All the previous suggestions didn't fix it for me. In the remote settings (JSON) I am now trying

    "remote.WSL.fileWatcher.polling": true,
    "files.watcherExclude": {
      "**/.git/**": true
    },
    "git.enabled": false,
    "git.autofetch": false,
    

    Not field-tested yet. This completely deactivates Git integration — but I use Git from my console (on Windows, not WSL) anyway.

  23. Reedbeta commented on Jun 28, 2021

    @Reedbeta

    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.)

  24. jtstanley commented on Jan 18, 2022

    @jtstanley

    robross0606 I'm having the same difficulty as you on WSL2 (i.e. with only WSL and Git, independent of VS Code):

    #903 (comment)

    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.

  25. scoussens commented on Feb 3, 2022

    @scoussens

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

bugIssue identified by VS Code Team member as probable buggit

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions