SCM: Gutter diff provider selection when multiple providers available

[alexandruavadanii]

Type: Feature Request

I think this should be a feature request, but it might just be a bug and the support already present and broken or incomplete.

When multiple SCM providers are available, and especially if the SCM repositories overlap, the gutter decorations seem to be generated by a single (non-selectable) SCM provider.

In the screen capture below, where a ClearCase SCM is present (and according to that SCM, the current file contains only 10 small changes), the GIT SCM is used for the gutter decorations. That leads to all the lines in that file having a blue "modified" marker based on that file's status in the GIT repository.

I would like to be able to choose which of the SCM providers should be used for gutter decorations, not only for inline diffs.

For testing purposes and ruling out the SCM provider as the source of the problem, consider the following scenario for demo purposes:

• SVN extension installed (I could use 2 nested git repositories, but I think it's better if I mention 2 different SCMs for clarity);
• workspace root is also the root of a SVN repository;
• workspace root contains one subdir that is the root of a GIT repository;

A file that resides in subdir will of course show up in both SCMs. If it's committed in both SCMs, we can even diff it (correctly) with its previously committed versions in each SCM.

However, the gutter diff seems to pick up the SVN SCM, no matter whether I reorder the SCMs in the SCM view, mess with the names to force a different order etc.

In this particular case, if I click the gutter decoration, the action being the default diff, I get the behavior presented below. I was expecting a dropdown menu letting me choose which SCM to use for the inline diff (as in the screen capture above). That might be a problem with the SVN extension or a bug, but it's outside the scope of this ticket - I'm only interested in the gutter diff decorations provider selection ability.

The SVN extension might not be the best to reproduce this, maybe nested GIT repos would work. And pardon the commited typo above, just noticed it.

VS Code version: Code - Insiders 1.84.0-insider (46982792873b62b7ad1099799f7f7f2c6eafde3f, 2023-10-26T05:35:19.063Z) OS version: Windows_NT x64 10.0.18362 Modes: Remote OS version: Linux x64 4.18.0-372.19.1.el8_6.x86_64 Remote OS version: Linux x64 4.4.0-64-generic

[vscodenpa]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[starball5]

Related on Stack Overflow: In VS Code, how can I choose which source control provider is used for diff decorations?

[alexandruavadanii]

@starball5 Thanks, that wasn't me.

If you or the SO user(s) are interested in this, vote for this ticket by clicking the thumbs up icon and if it receives enough votes, it might be prioritized at some point.

I haven't looked for alternative solutions, although this particular problem has been nagging me for a couple of months.

[vscodenpa]

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[starball5]

Would the https://github.com/microsoft/vscode/blob/main/src/vscode-dts/vscode.proposed.scmSelectedProvider.d.ts proposal be of any help here?

[alexandruavadanii]

@starball5 not really, that only exposes the SCM selection state.

I actually had a closer look at the code, thinking that maybe this is easy to change:

• all quick diff providers are gathered in https://github.com/microsoft/vscode/blob/0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2/src/vs/workbench/contrib/scm/browser/dirtydiffDecorator.ts#L1221
• all quick diffs are parsed and 2 relevant objects are constructed, changes and mapChanges in https://github.com/microsoft/vscode/blob/0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2/src/vs/workbench/contrib/scm/browser/dirtydiffDecorator.ts#L1386
• changes contains all quick diffs from all providers;
• mapChanges contains references to the changes quick diffs, indexed by the quick diff provider label;
• if enabled, when clicking the gutter, a widget is created that shows the dropdown I initially thought we could hook up to, but that dropdown uses mapChanges, unlike the gutter decorations that relies on the coalesced changes;

I did some hacky experiments:

• filtering both the gutter diff decorations and dropdown widget available changes by quick diff provider label, i.e. in https://github.com/microsoft/vscode/blob/0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2/src/vs/workbench/contrib/scm/browser/dirtydiffDecorator.ts#L1395

  this._quickDiffsPromise = this.getOriginalResource().then(async (allQuickDiffs) => {
  //...
  //HACK: limit gutter decorations AND dropdown widget to only quick diff providers that start with 'g', e.g. 'git'
  const quickDiffs = allQuickDiffs.filter(quickDiff => quickDiff.label.match(/^g/i) !== null);

• filtering only the gutter diff decorations by quick diff provider label, i.e. in https://github.com/microsoft/vscode/blob/0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2/src/vs/workbench/contrib/scm/browser/dirtydiffDecorator.ts#L1144

  //HACK: limit gutter decorations to only quick diff providers that start with 'g', e.g. 'git'
  const decorations = this.model.changes.filter(change => change.label.match(/^g/i) !== null).map((labeledChange)

While it's not hard to filter changes when building the gutter decorations, I realized it's not clear how this should be presented to the user:

• should we limit the gutter decorations to the quick diff provider selected by the dropdown in the widget? Those 2 are currently logically decoupled and the widget doesn't store the dropdown selection, it updates that based on the currently selected change. I thought about adding a checkbox next to the dropdown with something like "limit the gutter diff decorations to this quick diff provider", but that is a bad idea since the dropdown will not list quick diff providers that don't have changes for the current file;
• should we add another section in the SCM view context menu that allows selecting which SCM is allowed to contribute its quick diff provider (if available)? That will probably not work with the upcoming API that allows anyone to provide a quick diff provider, not only SCM ...

So, while hacking the code to limit the gutter decorations is not that complicated imo, I have no idea how to handle the UX for constructing the actual filter.

@alexr00 I saw you added this to the backlog, thank you for that! Do you have something in mind for how this should look like?

Also, if it helps, I can provide a git repository that also contains a Mercurial (hg) repository inside for reproducing the problem. You'll have to install an extension from the marketplace for that though.

[alexr00]

@alexr00 I saw you added this to the backlog, thank you for that! Do you have something in mind for how this should look like?

Currently no, I don't have a good answer for what this should look like. That's part of the reason we didn't add this feature when we added the API proposal that allows anyone to provide a quick diff provider. That new API makes a feature like this even more important, which is why I added this issue to the backlog.

Any entry point we have to choosing which quick diffs show in the gutter needs to be independent from SCM. Maybe a right-click menu that shows on the gutter decoration? @hbons do you have any ideas?

Whatever we decide, we need to figure it out before https://github.com/microsoft/vscode/issues/169012 can be finalized.

[alexr00]

Tentatively adding for February because I wanted to start finalizing https://github.com/microsoft/vscode/issues/169012.

[alexandruavadanii]

I think this should "feel" similar to an image editing software layer editor. But I don't have a better idea than gutter right click menu on where it could be hooked, but I'm no designer...

For a start, I'd be happy if we could enable/disable a QuickDiffProvider for the current file and/or globally, although it would be really awesome if we could assign different colors & priorities for different providers.

[gjsjohnmurray]

@alexr00 are there any plans to finalize this API?

EDIT - this question belongs better on #169012 so I will ask it there.