Git actions are enabled when doing a simple "Compare Selected"

[thw0rted]

• VSCode Version: 1.22.2
• OS Version: Windows 10 (current)

Steps to Reproduce:

1. Select any two files in Explorer view
2. Right click -> Compare Selected

The resulting comparison pane has a number of issues carried over from when it was exclusively for comparing versions in a source-control context.

• You can't edit the left-most (first selected) file. In this context, that makes no sense, since they're both just files on disk.
• Select a range -> Stage Selected Ranges, results in a Git error dialog ("cannot add to the index").
• The Unstage command does nothing (no error message)
• Revert Selected Ranges totally hoses the file, I'm not totally clear on what it's removing or why but it's pretty bad.

The command menu should instead include "Copy to right/left" actions as in #25887. Broadly, the comparison view should optionally treat the left side as read-only (which makes sense in git diff context) and at least stop using "stage" actions when not opened by a source-control provider. IMHO, "left/right" terminology is always clear while "stage/unstage" is only helpful in very limited context.

[joaomoreno]

For not being able to edit: #4180

I'll leave the issue open to address the fact that those Git actions shouldn't even be there when doing such comparisons.

[joaomoreno]

@bpasero I wonder if the vscode.diff command could accept context keys to be set in that diff editor, such that we can scope commands to those context keys?

[bpasero]

@joaomoreno are you referring to the "Open File" action?

[joaomoreno]

Nah, to the vscode.diff API command.

[bpasero]

@joaomoreno I suggest that the diffEditorWidget adds another context key similar to isInDiffLeftEditor and isInDiffRightEditor that includes the scheme portion of the URI so that your commands can register based on the resource scheme and not for every diff editor.

@alexandrudima to comment if that is OK to add to that widget.

[alexdima]

We can put the entire URI, I don't mind. Do we do that for a regular editor as well? If yes, we could just try to reuse the same key / same implementation.

[bpasero]

We do have ResourceContextKey which splits a URI into many different context keys, not sure all of that is needed though.

[alexdima]

ping @jrieken for opinion -- how should we represent the two diffed resources in the diff editor? Should we attempt to reuse ResourceContextKey ?

[bpasero]

I believe we need a prefix for the diff editor though to support both left and right hand side. In theory both sides are "active" (maybe not focused). So we could have 2 resource context keys (original, modified) for the diff editor.

[bersbersbers]

This issue arises more frequently now that the timeline view has been added. Basically, every commit in the time-line opens a diff viewer/editor with two read-only files (which is correct) of which the right one still offers actions such as "Stage", "Unstage", "Revert", see snapshot*. These actions do not seem to do anything.

• This snapshot shows the last commit: if there are no local changes in the working copy, these actions could actually have some meaning, which makes it all the more confusing that they don't do anything.

"Compare against workspace file" in the "Git History" extension does something similar. There, a diff editor is opened that on actions such as "stage" returns errors such as

"Git: cannot open git:/tmp/old-hash... Detail: Unable to read file 'git:/tmp/old-hash...:"~"}' (EntryNotFound (FileSystemError))