search

microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
162.28k stars 28.57k forks source link

Random Git fails to locate .git folder on VSCode start #137002

Closed TonyGravagno closed 2 years ago

TonyGravagno commented 2 years ago

Issue Type: Bug

Start VSCode, open a workspace. Git does not find a .git folder in subfolders of the workspace root. In this scenario the .git folder is within the project, not at the root of the workspace.

This has happened in the past. I could not intentionally reproduce the issue until now.

This is a WordPress PHP project where I'm writing a plugin/extension. Workspace root is /public and nested folders are /wp-content/plugins. In there the plugin folder is 'myplugin' and the .git folder is in there. So it needs to find /public/wp-content/plugins/myplugin/.git.

I work on this project every day with no issues. Commit, Push, close workspace, exit VSCode, shutdown, restart the next day. On rare occasion, on restart it no longer scans down to find the .git folder and thus offers to initialize a new repo.

It seems to scan files in the root /public, not folders. The option to scan subfolders was set to true, didn't work. Set to 'subfolders', no joy. Tried positioning to 'myplugin' folder, change that setting to force a rescan - it starts at public and stops.

The issue is resolved by going to File Explorer and simply opening the Git log for the folder/repo. (I use TortoiseGit) VSCode then recognizes the repo and it's all good afterward.

Before the log is run, messages like this display in Output window:

Opening repository for path='d:\path…\public' failed; ex=Failed to execute git { "exitCode": 128, "gitErrorCode": "NotAGitRepository", "gitCommand": "rev-parse", "stdout": "", "stderr": "fatal: not a git repository (or any of the parent directories): .git\n" }

Those messages repeat for PHP and JS files in the root and some subfolders - not for folders! On restart of VSCode many more errors are displayed as it does the scan on files in 'public', not folders. I've attached a file with that output. vscode_git_log.txt

Note the consistent exception in that log:

Opening repository for path='d:\path...\subfolder\filename' failed; ex=spawn C:\Program Files\Git\cmd\git.exe ENOENT {
  "gitErrorCode": "NotAGitRepository"
}
Error: spawn C:\Program Files\Git\cmd\git.exe ENOENT
    at Process.ChildProcess._handle.onexit (internal/child_process.js:269:19)
    at onErrorNT (internal/child_process.js:465:16)
    at processTicksAndRejections (internal/process/task_queues.js:80:21)

I wonder if I might have changed a setting or disabled an extension that is now causing these seemingly unrelated issues.

When the Git log is opened in File Explorer, the Output window in VSCode displays the output. OK, I don't get that, but it's cool.

Output when external process executed, may not be relevant > \> git rev-parse --git-dir > Open repository: d:\path…\public\wp-content\plugins\myplugin > \> git status -z -u > \> git symbolic-ref --short HEAD > \> git for-each-ref --format=%(refname)%00%(upstream:short)%00%(objectname)%00%(upstream:track) refs/heads/0.10 refs/remotes/0.10 > \> git for-each-ref --sort -committerdate --format %(refname) %(objectname) %(*objectname) > \> git remote --verbose > \> git config --get commit.template > \> git check-ignore -v -z --stdin

The repo is then available from the myplugin folder and the Git branch shows in the bottom status bar.

Now, to reproduce:

It seems the issue is that the .git folder is hidden to VSCode until it is provoked into recognizing it, maybe by a FileWatcher that's looking for a read on the subfolder tree (?). There is no .gitignore anywhere up the folder tree that would cause .git to be ignored.

Also note: I have the entire WordPress application as the root of this workspace and it includes many folders and files. I'm wondering if there is a limit for how many folders down the tree it will scan, or perhaps a path length limit. Remember though that I work on this project every day with no issues until today ... and this issue only rarely/randomly in the past - I believe in those rare instances this only occurred after a VSCode update.

This issue started this morning without any obvious incident. VSCode was updated to the latest version a week ago and the program has been stopped, system restarted, many times since that event. I don't think any other updates have occurred, though Win10 might have had a patch during this time.

I hope the condition persists so this can be diagnosed. I'm happy to do whatever I can to find and fix this.

VSCode and dependencies VS Code version: Code 1.62.1 (\f4af3cbf5a99787542e2a30fe1fd37cd644cc31f, 2021-11-05T10:57:55.946Z) OS version: Windows_NT x64 10.0.19042 Restricted Mode: No Electron: 13.5.2 Chrome: 91.0.4472.164 Node.js: 14.16.0 V8: 9.1.269.39-electron.0
System Info |Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i7-10875H CPU @ 2.30GHz (16 x 2304)| |GPU Status|2d_canvas: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
oop_rasterization: enabled
opengl: enabled_on
rasterization: enabled
skia_renderer: enabled_on
video_decode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled| |Load (avg)|undefined| |Memory (System)|31.82GB (17.82GB free)| |Process Argv|--crash-reporter-id 3555131d-7d56-4887-a807-ceafc2556f0b| |Screen Reader|no| |VM|0%|

Extensions not relevant to current project are disabled.

Extensions (21) Extension|Author (truncated)|Version ---|---|--- auto-align|bla|0.0.13 vscode-intelephense-client|bme|1.7.1 wpcs-whitelist-flags|cla|1.1.0 easy-php-error-logger|dhi|1.0.0 php-debug|fel|1.22.0 php-pack|fel|1.0.2 code-runner|for|0.11.6 todo-tree|Gru|0.0.214 vscode-wordpress-hooks|joh|0.6.0 regionfolder|map|1.0.15 php-namespace-resolver|Meh|1.1.8 phpformbuilder|Mig|0.0.1 remote-ssh|ms-|0.66.1 remote-ssh-edit|ms-|0.66.1 php-docblocker|nei|2.6.1 vscode-php-getters-setters|php|1.2.3 format-html-in-php|rif|1.7.0 rogeriopradoj-php-refactor|rog|0.0.6 php-imports|tar|0.5.1 vscodeintellicode|Vis|1.2.14 searchwpdocs|yog|2.0.1
A/B Experiments ``` vsliv368:30146709 vsreu685:30147344 python383:30185418 vspor879:30202332 vspor708:30202333 vspor363:30204092 vswsl492cf:30256860 vstes627:30244334 pythontb:30283811 pythonvspyt551:30345470 pythonptprofiler:30281270 vshan820:30294714 vstes263cf:30335440 vscorecescf:30384386 pythondataviewer:30285071 vscod805:30301674 pythonvspyt200:30340761 binariesv615:30325510 vsccppwt:30382697 bridge0708:30335490 dockerwalkthru:30377721 bridge0723:30353136 pythonrunftest32:30373476 pythonf5test824:30373475 javagetstartedt:30391933 pythonvspyt187:30373474 vsqsis200cf:30386380 vsaa593:30376534 vssld246:30386377 ```
lszomoru commented 2 years ago

@TonyGravagno, sorry to hear about the issue. Are you saying that right now you have a consistent way to reproduce the issue?

I have looked at the .git folder discovery code and I am not seeing any recent changes in that are of the code. By default VS Code is detecting any .git folder that is an immediate child folder of the workspace folder. This behaviour can be tweaked using the git.autoRepositoryDetection setting. You can use the git.scanRepositories setting to specifies locations to scan for repositories as well as the git.ignoredRepositories setting to ignore repositories.

TonyGravagno commented 2 years ago

Thanks for your interest! I'm citing UX issues as well as a functional issue with .git folder auto-detection. I appreciate your patience as I try to put this all together here...

As noted, my .git folder is not "an immediate child folder of the workspace folder".

I was not understanding the rules of each option of auto repository detection. I had the impression that opening any file in any subfolder, should cause .git folder detection for that file. It does not. Open a file in the folder that contains .git, change and save the file, there is no indication of activity to find a .git folder.

I was thinking option 'subfolder' would cause a deep scan of all folders for .git folders when the workspace is opened. That's not correct. It seems by design it only scans the current folder, to a depth of 1. This is fine, though it might be worth considering a deep scanning on opening a workspace rather than doing it all the time on file open.

When opening the Git icon from the sidebar the text says "The workspace currently open doesn't have any folders containing git repositories." That is misleading. My workspace does have a folder with a git repo, that folder is just not at the top level and the detection isn't looking deeper.

I would hope that when we use the Explorer to click on a folder that includes a .git repo, that then opening the Git option would scan the current folder to detect a .git subfolder.

Per your suggestion I did use the git.scanRepositories option to specify the folder that contains the .git folder. This is not detected even on close of workspace and re-open. I tried a full path and a relative path to the workspace root.

The only way I see to trigger recognition of the .git folder is as noted in my OP: Check Git log in File Explorer. Somehow this triggers VSCode. That is, just opening the Git Log outside of VSCode causes the VSCode application to refresh and show the repo detail.

Does any of this help? Thanks again.

TonyGravagno commented 2 years ago

I have a 100% repeatable condition where auto .git folder detection fails and it can be triggered to detect.

Repeating details more concisely than earlier....

VSCode v1.62.3 over W10. Workspace path is D:\path1\path2\wsroot Git folder is in D:\path1\path2\wsroot\path4\path5\path6\src\.git git.scanRepositories: [ "D:\\path1\\path2\\wsroot\\path4\\path5\\path6\\src" ]

ctrl-shift-G to open SC. Shows no repo detected. Open a file in the src folder, SC is not detected. Make a small change and save the file. SC is not detected. From terminal: touch D:\path1\path2\wsroot\path4\path5\path6\src\.git\description The repo is detected when a file in the .git folder changes.

So the folder scan is not finding a .git folder under the git.scanRepositories. The file watcher does not detect a .git folder at the same level where a file is changed. But file watcher does detect a change in a .git folder.

In settings.json:

The value of files.legacyWatcher is not relevant. I turn off the legacyWatcher to resolve another issue.

The git.scanRepositories setting may have some limit or requirement that I'm not conforming to. I've tried adding trailing slashes, and pointing directly to the .git folder, with no success.

I setup the tasks.json below. On opening the workspace, a touch command is executed and now the SC is detected without manual intervention.

Please let me know if I can provide any other info. Thanks.

tasks.json with auto tasks allowed ```json { "version": "2.0.0", "tasks": [ { "label": "Force repo detection on Startup", "type": "shell", "windows": { "command": "touch D:\\path1\\path2\\wsroot\\path4\\path5\\path6\\src\\.git\\description" }, "presentation": { "echo": true, "reveal": "always", "focus": false, "panel": "shared", "showReuseMessage": true, "clear": false }, "runOptions": { "runOn": "folderOpen" } } ] } ```
lszomoru commented 2 years ago

@TonyGravagno, thank you very much for the detailed description. I will try to repro and get back to you.

lszomoru commented 2 years ago

@TonyGravagno, I think that I was able to track down the issue. One thing that I have forgot to ask you is whether the workspace is in "Restricted Mode" or not. Could you please open the workspace, and then choose the Manage Workspace Trust command in the command palette and make sure that you trust the current workspace. The git extension has some limitations when it comes to repository discovery when the workspace is in "Restricted Mode". If the workspace is trusted, as soon as you open a file from the "src" folder, the SCM viewlet should be updated. Can you please try that out and let me know if it works.

The second issue, is that there seems to be a regression in handling the git.scanRepositories setting and the list of folders is not being honoured independent whether you are in "Restricted Mode" or not. This is something that I will be looking at fixing early next week.

lszomoru commented 2 years ago

The second issue, is that there seems to be a regression in handling the git.scanRepositories setting and the list of folders is not being honoured independent whether you are in "Restricted Mode" or not. This is something that I will be looking at fixing early next week.

This issue has been fixed with d6f24e10d55b337bb09f5e8f39b8011fa4856d82.

Give your scenario:

Should should use the following setting: git.scanRepositories: [ "path4\\path5\\path6\\src" ]

lszomoru commented 2 years ago

To verify:

rchiodo commented 2 years ago

/verified

stable repros issue using verification steps insiders does not.

TonyGravagno commented 2 years ago

Verified in production 1.63. Thank you!