Interference with Git context switches - Uncontrolled auto save for "in memory" file

[FALLAI-Denis]

Hi,

First of all, thank you for proposing this extension which we fully appreciate.

We noticed an issue when using it in a Git context. When the user works in a Git branch whose sources have TODO tags, and he makes a Git branch change, (checkout), the TAG tree is not erased and recreated for the context of the new Git branch, but above all, the links stored in the TAG tree cause the display of a source which possibly does not even exist in the new Git branch...

It is of course possible to activate the todo-tree.general.automaticGitRefreshInterval setting, but this will actually occurs after the Git branch change, and it seems that the TAG tree locks the referenced sources and prevents Git areas from being refreshed by checkout.

The case of a source that does not exist in the new Git context is obvious, and this is what attracted the attention of our developers, but the biggest danger would be to work with a source that exists in the old Git context and the new Git context, and after a Git context change the developer ends up with the source of the old context. For the moment we have not highlighted this problem, but that of the file which does not exist in the new Git context and which is displayed when we click on the link in the TAG tree has been observed several times.

This issue was noticed after implementing the TODO Tree extension and did not occur before that.

Thanks.

[FALLAI-Denis]

PS: I think I found the conditions of the problem...

• The issue occurs when a file that only exists in the context of a current Git branch is opened in a VS Code editor
• When changing Git branch, to go to a Git branch where the file does not exist, we see that the text indicating the name of the file in the VS Code editor tab is first strked, then quickly is no longer striked out and the file then appears in the list of files not tracked by Git, (U mark)
• I think it's the application of "decoration" to the text opened in the VS Code editor that causes it to be saved to disk, and makes it appear as an untracked file in Git
• Git is not the cause of the problem, but reveals the problem.

However, the problem does not seem systematic and seems to only occur in the event of a "first" time on a file: if it has been highlighted 1 time on a file, it is not possible to reproduce the case on the same file. Perhaps the number of editors open in VS Code also has an influence on the occurrence of the problem.