Only create a “source control provider” for folders added to the project (vscode refuse-to-fix bug workaround)

[ghost]

I frequently have hundreds of source control providers listed for a window, not intentionally but due to refuse-to-fix bugs/major design errors in VSCode itself (microsoft/vscode#76262 microsoft/vscode#101819). It frequently does not open files opened from the command line, including SyncTeX backward search from a PDF viewer, in the correct and logical window, i.e., one containing the project to which the file belongs. If vscode is working idiotically yet predictably and half-correctly, it opens the file in the previously active window, but sometimes it goes into a “state” and opens all files in a fixed window (even if the file is already open in another window, which was also previously active). Both of these situations cause the Mercurial repositories containing those files to be added as source control providers for that wrong window. Closing the tab with file that should have been opened in another window does not remove the source control provider. This causes the source control providers to accumulate.

I'm not sure if it's even under the control of the vscode-hg extension, but if it is, I would recommend to either:

a) only create a “source control provider” for the repositories/folders (and their subrepositories) explicitly added to the project open in a window, or

b) auto-close source control providers for files in folders not explicitly added to the project, when all files in that repository have been closed.

[hdpoliveira]

Hi @yadayadaydadaa

I'm not sure we can do these. Letter a is asking for us to drop consistency with the way other SCM extensions are implemented (which we don't want), while letter b is not feasible.

You are right: this seems an issue in vscode itself. Trying to fix it at our level would not be productive.