There's a growing number of ways you can get a diff view in VSCode. Some that I know of are:
- Clicking a line on the timeline view
- Selecting 2 files and choosing "Compare Selected"
- Git built-in extension clicking on the Source Control view
- Gitlens clicking on various UI elements to show a split view
- Github Pull Requests and Issues extension which shows a split view when looking at PRs
After reviewing the changes in a diff view it's common to go back to the original (or changed) file. But this is where the workflow falls apart. Sometimes there isn't a way to get back to the original view, or the UI has a different approach to doing it depending on where you came from.
- Git has "Open File" which you can tie to anything (not bounded to anything by default)
- GItlens also has "Open File" which isn't bounded to anything by default, often set to something else even though its used in the same context.
- Github Pull Requests and Issues has another way of doing it also (no shortcut but a new button).
- Timeline, I don't know if it provides anything for this, so you have to manually navigate
The point is, it's cognitively difficult to remember 4 or 5 different ways of performing the same action. Can VSCode provide a shortcut/UI to do this which maps to the same keybinding for extensions to use? I understand some times a view cannot be opened so that would need to be accommodated (maybe nothing happens). The issue right now is every extension is implementing their own way of opening/closing diff views.
What is expected
Hopefully the below helps to put this into more context. I'll come up with a hypothetical "shortcut" just to illustrate what would be expected as being consistent behaviour across Code and it's extensions.
Assuming ctrl+cmd+o along with when: isInDiffEditor is used as an "Open File" shortcut. I will refer to this as "Open File" below.
Timeline Split View
- [Setup] Clicking a previous entry on the timeline opens diff view
- Toggling "Open File" on the current version would be the same as opening that current file
- Toggling "Open File" on the older version would be the same as calling "Show Contents" which shows the version being looked at in a single pane
Compare Selected
- [Setup] Selecting 2 files and choosing "Compare Selected"
- Toggling "Open File" on one split opens that file in a single pane
- Toggling "Open File" on the other split opens that file in a single pane
Source Control (Split View)
- [Setup] Making a change to a file, then going to Source Control and clicking the file in the staging area triggers a split view
- Toggling "Open File" on the HEAD pane should should be the same action as
git.openHEADFile (currently unbound)
- Toggling "Open File" on the changed pane should should be the same action as
git.openFile (currently unbound)
Other Extensions
Third-party extensions is where it becomes tricky, but I would expect them to follow the same standard. So using the same "Open File" command/shortcut should allow the user to open that split in a single pane. I know Gitlens already support this so it wouldn't be too difficult for it to use the same shortcut for consistency.
There's a growing number of ways you can get a diff view in VSCode. Some that I know of are:
After reviewing the changes in a diff view it's common to go back to the original (or changed) file. But this is where the workflow falls apart. Sometimes there isn't a way to get back to the original view, or the UI has a different approach to doing it depending on where you came from.
The point is, it's cognitively difficult to remember 4 or 5 different ways of performing the same action. Can VSCode provide a shortcut/UI to do this which maps to the same keybinding for extensions to use? I understand some times a view cannot be opened so that would need to be accommodated (maybe nothing happens). The issue right now is every extension is implementing their own way of opening/closing diff views.
What is expected
Hopefully the below helps to put this into more context. I'll come up with a hypothetical "shortcut" just to illustrate what would be expected as being consistent behaviour across Code and it's extensions.
Assuming
ctrl+cmd+oalong withwhen: isInDiffEditoris used as an "Open File" shortcut. I will refer to this as "Open File" below.Timeline Split View
Compare Selected
Source Control (Split View)
git.openHEADFile(currently unbound)git.openFile(currently unbound)Other Extensions
Third-party extensions is where it becomes tricky, but I would expect them to follow the same standard. So using the same "Open File" command/shortcut should allow the user to open that split in a single pane. I know Gitlens already support this so it wouldn't be too difficult for it to use the same shortcut for consistency.