microsoft / vscode

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

Git Extension's onDidChange does not report branch changes #189316

Open phil294 opened 1 year ago

phil294 commented 1 year ago

Does this issue occur when all (other) extensions are disabled?: Yes

Steps to Reproduce:

  1. Write an extension that uses git api:
  2. extensions.getExtension('vscode.git').exports.getAPI(1).repositories[0].state.onDidChange(() => console.log('repo change!'))
  3. works great for most changes to the current repo such as stashing or committing. The event contains no data as discussed in #142313 but this is as designed
  4. Now add a branch via command line as git branch new-branch
  5. onDidChange does not fire!

It kind of makes sense as VSCode's Git extension does not include proper branch management by itself, but for depending extensions, this is quite annoying. Here's the bug report for my extension: https://github.com/phil294/git-log--graph/issues/27 (forget about the "stashing"-part, this is unrelated and actually works)

lszomoru commented 1 year ago

@phil294, thank you very much for reporting this issue. The onDidChange event is meant to fire every time after a git command is being executed using the VS Code git UX. VS Code will also execute git status in response to file system change events which VS Code is focused so that would also result in the onDidChange event being fired.

If you create a sample extension with the code above and see the console message if: 1) you use the "Git: Create Branch..." command to create a new branch 2) run git checkout -b <BRANCHNAME> in the integrated terminal

I can confirm that running git branch <BRANCHNAME> in the integrated terminal will not result in the event being fired so I am suspecting that the file system event occurs in a folder/file that we are not currently watching. I will investigate further and will update the issue with my findings.

lszomoru commented 1 year ago

I have looked into this and I can confirm that running git branch <NAME> is creating a new file in the refs/heads folder which we are not currently watching. Watching the refs/heads folder is an option but that could have performance implications due to the large number of files that may exist in that folder so I would rather wait for this proposed API to land. This will enable the vscode.git extension to refresh the "Source Control" view when a git command is executed in the integrated terminal.

phil294 commented 1 year ago

ok, I see. That wouldn't help for folks who use an external terminal though :/

Why would it be slow though? I tried to figure out the internals of createFileSystemWatcher but was unable to, there's 50 abstraction layers in the code before you get to the actual implementations and I got lost somewhere on the way. But anyway, isn't the implementation using some sort of fs.watch internally which uses inotify/kqueue etc. (contrary to the polling fs.watchFile) and should consequently run reasonably fast regardless of the amount of branches in .git/refs/heads? Sorry for the rookie question