Vscode-git-graph: Ability to compare branches (actually, commits)

Created on 12 Mar 2019  ·  11Comments  ·  Source: mhutchie/vscode-git-graph

Thank you so much for this awesome extension. I used to use the Git History extension but immediately switched to yours since I found it (and left the first 5 ⭐ review of your extension 😎).

Describe the feature that you'd like

Select a commit for comparison, then select another commit to compare

Additional context (optional)

demo

(This is just an example of what Git History does. I don't think it is a good idea to show the comparison in the file explorer)

feature request

Most helpful comment

The ability to compare two commits will be available in v1.5.0, and will be released in the next day. I've reopened #36 (which requested broader support for uncommitted changes), so I'll extend the commit comparison to support the working tree as part of that feature request in the next release (in the next week).

To compare two commits, click on one of the commits (to open the Commit Details View), and then CTRL / CMD click any other commit to compare it with.

All 11 comments

Thanks for the feedback! This suggestion seems quiet useful, I’ve also used this type of commit comparison in the past.

I just need to think about how it would be best to display this information. I agree that it shouldn’t be in the file explorer, so I just need to find a nice way of showing it in the existing interface.

To piggyback on this feature request, it'd be awesome to also be able to compare commits from the past against the current uncommitted state. Thanks for a great extension!

Agreed, ability to compare a commit with working tree would be amazing!

The ability to compare two commits will be available in v1.5.0, and will be released in the next day. I've reopened #36 (which requested broader support for uncommitted changes), so I'll extend the commit comparison to support the working tree as part of that feature request in the next release (in the next week).

To compare two commits, click on one of the commits (to open the Commit Details View), and then CTRL / CMD click any other commit to compare it with.

It seems like the order of selecting the commits doesn't change the order of comparison (from commit A to commit B). Is it by design?

Yes, the order of selecting commits doesn’t change the order of comparison. It will always show changes from the oldest commit to the newest commit.

I've now completed the ability to compare any commit with the uncommitted changes as part of #36. This will be available in v1.6.0. I have implemented:

  • View uncommitted changes
  • Comparing any commit with the uncommitted changes
  • Three new Git actions from the new Uncommitted Changes context menu:

    • Reset uncommitted changes to HEAD

    • Clean untracked files

    • Open the Visual Studio Code Source Control View

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

Thanks for the reply. Any consideration for this oldest-newest order?

A disadvantage is, we cannot select/copy the deleted text from _the old version_ in the vscode diff view. microsoft/vscode#8226

I thought the oldest-newest order made sense as:

  • The old version of the file is always on the left, and the new version of the file is always on the right of the diff view, for consistency.
  • I felt it would be confusing to have the newest version of the file on the left.
  • The diff should be clearly interpretable from the Diff view alone, so the only way to allow the reversed ordering would be to change the tab title. I didn't pursue this at the time as I couldn't come up with a consistent pattern for a new tab naming scheme allowing the ordering to be easily differentiated (especially with the new beta support for uncommitted changes).
  • This is consistent with the built in usage in the VS Code SCM view when viewing staged/unstaged files.

@yzhang-gh I wasn't aware of this limitation with the VS Code Diff View, which is quite unfortunate.

For now I'm inclined to leave it as is, however I'll have a think if there is anything else I could do to work around this limitation.

I agree with you on most of the points.

Just to add another point. When we are comparing two commits from different branches, it is hard to say which one is "older" 😥

If you want the UI to work the same as other tools that I have used (TortoiseGit & GitExtensions) then the order of the clicks would matter. For those applications, the diff is displayed as how the 2nd click differs from the 1st clicked commit.

Was this page helpful?
0 / 5 - 0 ratings