Fix #16412: if a resource contains both staged and unstaged changes, selection in the SCM panel was not reliable

[xpomul]

What it does

Adds the necessary code to resolve the URI back to the ScmGroup.

Missing: handling of PluginScmProvider

How to test

Test Setup Instructions:

• Clone a repo with at least one file that can be staged and modified again (let's call it file.txt.
• Ensure Git is enabled in the workspace.
• Switch to the Source Control: Git panel.

Test Cases / Test Steps:

• Edit file.txt, save, and stage the changed file.txt. Verify that file.txt appears in the Staged Changes group.
• Edit file.txt again. Verify that file.txt appears both in the Changes and Staged Changes groups.
• In the SCM panel, click the Unstaged file.txt.
• The diff editor (index vs working tree) is opened.
• The unstaged file.txt is selected in the SCM panel.

Follow-ups

Breaking changes

• This PR introduces breaking changes and requires careful review. If yes, the breaking changes section in the changelog has been updated.

(added getScmGroupIdForUri() to ScmProvider interface, but the method is optional, so not actually breaking...)

Attribution

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines

[ndoschek]

Hi @xpomul,
Sorry for the delay on this. I checked your state, and as @msujew mentioned in the ticket, the changes in packages/git should be reverted.
Nevertheless, I think we can use the details of the passed URI argument to determine which group it should belong to. The query part indicates, for example, whether it has already been staged or not.
I did a quick test with the attached snippet (which is just a POC 😅), but only for the specific scenario you mentioned, since there are other groups as well (e.g., merge). Would be great if you could also test the other cases, like files with merge conflicts, to make sure the solution holds up across all scenarios.

[colin-grant-work]

Looking at VSCode, I think there's a difference in behavior here. In VSCode, if you have diffs open of the same file from two states (staged and unstaged) and you switch focus between the diffs, the SCM tree does not change selection, even if the currently selected item is not related to those two diffs. On the other hand, if you have the original file open and switch to that, VSCode will switch selection to the last item in the tree corresponding to that file, if the selection was on something that is not related to that file. I think that this is because VSCode does not coerce the URI to a file scheme URI, as we do here. That means that only URI's that match the source scheme (presumably mostly file) change the SCM tree's selection, so the git scheme URI's on diffs don't produce any change, so opening a diff with doesn't shift the SCM tree selection.

Nevertheless, I think we can use the details of the passed URI argument to determine which group it should belong to. The query part indicates, for example, whether it has already been staged or not.

I don't think this is a safe procedure, because both the URI's used for diffs and the groups in the tree themselves are generated by extensions, so we can't assume anything about how the properties of a given URI do or don't map onto group affiliation.