Add option to open diff with working tree

[ghost]

Hi,
It would be nice if I have the possibility to compare a selected file from a commit with the current working tree to be able to make changes in the diff view.
Something like this:

Furthermore it would be nice to have a button (on the Shortcut Menu Bar) or an entry in context menu to open the file from the current diff view. Like that one in the regular diff view:

[mhutchie]

Hi @hansunzner-kt,

Thanks for raising this feature request! I'll include both of them in an upcoming release.

[ghost]

Thanks!
What do you think of following:
Assume picking a diff view of a file from the last commit.
So the right side would be the same as the working directory if there were made no changes. Could you then make the right side editable?

[mhutchie]

Hi @hansunzner-kt,

Yes. the right side of the Visual Studio Code Diff View would be editable. This is equivalent to the Diff View opened when viewing the diff of a modified uncommitted change via the Git Graph View.

[ghost]

I meant that in a normal diff view, independently of this new feature.

[ghost]

What a pity that it didn't made it into the 1.29 😢

[mhutchie]

Hi @kt-unzner,

This feature should be available for you to use in a beta release within the next week or two. Git Graph 1.30.0 is currently scheduled for release on 28/03/2021.

[ghost]

This feature should be available for you to use in a beta release within the next week or two.

👍

Git Graph 1.30.0 is currently scheduled for release on 28/03/2021.

Yes I saw that. And that's adds the time I am still waiting for :-/

[mhutchie]

Both of these features will be available in v1.30.0 (which has been tentatively been moved forward by one week to 21/03/2021).

If you'd like to use them before the next release, you can download v1.30.0-beta.1, and install it following the instructions provided here.

[ghost]

Selecting "View Diff with Working File" enables now the possibility to edit a file in the diff view even if there are no changes to the file in the working directory -- that's very cool, thank you!

[ghost]

Astonishing how much more comfortable this little feature makes the working. Thanks again for this!
But another question:
When opening a file by the "Open File" button - is it possible to place the cursor of the just opened file to that position where it was in the diff view?

[mhutchie]

There are two main cases when Diff View's are opened via Git Graph:

1. The Diff's right side is the file on the file system (i.e. the working file) - in this case, pressing the "Open File" button on the Diff View does open the working file to the same line number.
2. The Diff's right side is the file at a historical revision (not the working file) - in this case, pressing the "Open File" button on the Diff View will open the working file (but not to a specific line number). Although it's possible to obtain the users current selected line number in the Diff View, and go to that line number in the working file, there's no guarantee that the selected "line of code" in the historical revision of the file refers to the same "line of code" in the working file.
   • For example: Between the historical revision and the working file, 500 new lines of code were added to the beginning of the file. If the user had selected Line 2 in the Diff View (before pressing "Open File"), then Line 2 of the working file would be incorrectly selected (when actually the "line of code" the user had selected is now on Line 502).
   • Users would almost certainly treat going to the wrong "line of code" as a bug (I share the same view). In this case I'd much rather just open the file (without going to any line number), as no one would treat it as a bug.

[ghost]

Case two is the regarding case. Usually I have a look on what has changed last to this file and then open it at this position to continue there. Maybe you have a better idea for this workflow?
So it is a historical commit but with no changes to the working directory. Of course it would only make sense to keep the line number when the right side is equal to the working dir. Can you keep the curser's line number when the right side equals the working dir? Or to enhance this: If the content up to this line is equal or contains only space changes.

[ghost]

Another question, not regarding this content:
Is there an option to view the stashes in the correct time order? Now it is always directly above the commit. Normally I would prefer this, but when comparing a stash to another commit, I would like to have the newest on top...

[mhutchie]

Case two is the regarding case. Usually I have a look on what has changed last to this file and then open it at this position to continue there. Maybe you have a better idea for this workflow?
So it is a historical commit but with no changes to the working directory. Of course it would only make sense to keep the line number when the right side is equal to the working dir. Can you keep the curser's line number when the right side equals the working dir? Or to enhance this: If the content up to this line is equal or contains only space changes.

Your suggestion definitely seems like the best way to deal with this scenario. The hesitation I have, is that it would be a reasonably complex piece of logic to implement, that will only benefit the user when the file hasn't changed. Additionally user's might see the behaviour as inconsistent, as sometimes it goes to the "line of code" they want, other times it just opens the file. Throughout the extension, I tend to avoid any behaviour that is inconsistent (from the users perspective). I'd like to get the "Open File" from Diff View feature released first, and see what feedback I get from other users. This will allow us to make a more informed decision on how much value this would give users (when it is possible to do so) - the more value added, the more it outweighs any concerns.

Another question, not regarding this content:
Is there an option to view the stashes in the correct time order? Now it is always directly above the commit. Normally I would prefer this, but when comparing a stash to another commit, I would like to have the newest on top...

Currently there isn't an option to view the stashes in the correct time order. As you mentioned, displaying the stash directly above the commit is generally what users prefer the majority of the time, however I definitely understand that there are edge cases where it's less than ideal. In the scenario when comparing a stash to another commit, one viewpoint is that regardless of the time of the stash, the vast majority of the codebase was at the stash parent's point-in-time - so the from-to order should be derived on the stashes parent compared to the other commit (the current behaviour). However this viewpoint could easily and equally be argued against.

There are definitely some ongoing dilemmas around the right way to order things. Thanks for letting me know your scenario, and how the current behaviour impacts you. All user feedback like this is collated, and actioned upon once enough users share the same opinion.

[ghost]

Thanks for detailed feedback.

I'd like to get the "Open File" from Diff View feature released first, and see what feedback I get from other users.

Ah yes I forgot that it is not official released yet. And I agree to get first some feedback from the users.

Another point: Your button "Open a Terminal" only opens a terminal as the name says. But the same looking button in the Shortcut Menu Bar toggles the terminal. May you want to adapt the bahaviour to the Menu Bar button?

[irvnriir]

Where is the feature at ? Its 1.30.0 .

[mhutchie]

Hi @irvnriir,

As mentioned in the release notes, this is included on the File Context Menu in the Commit Details View, not the Commit Context Menu (which is shown in your screenshot). The file context menu is shown when you right click on a file in the Commit Details View.

#457 New "View Diff with Working File" action on the File Context Menu in the Commit Details View.

[irvnriir]

@mhutchie thanks .

i have 1 Commit where it doesn't show X) . though it may be broken somehow -- the Commit also shows strange behavior at Cherry Pick .

Is there a setting to put it on the right side of Diff ? (so the new/green values would be ones from the selected file) To work with saved/stashed updates/changes .

[mhutchie]

Hi @irvnriir,

There are a few cases where "View Diff with Working File" isn't available in the file context menu (all of which are necessary for a specific reason). It's the same conditions as the "View File at this Revision" action on the same context menu.

Is there a setting to put it on the right side of Diff ? (so the new/green values would be ones from the selected file) To work with saved/stashed updates/changes .

Just to clarify, are you asking whether there is a setting to switch the left & right sides of the Diff View (i.e. so the working file is on the left side, and file that you right-clicked on is on the right side)? If so, it's a convention for consistency across Visual Studio Code (including extensions), that the oldest file is on the left, and the newest file is on the right (as the working file is the "newest" file, it's always on the right side).

[irvnriir]

@mhutchie oh, the editable is the right one, nm then . i guess i'm still with some kinetic from previous diff tool (and y, very tired) X) thanks for clarification and sorry for bothering :)

[mhutchie]

Hi @irvnriir,

All good, I'm glad I could help clarify the current behaviour.