Vscode-git-graph: Exclude specific intermediate commits from commit comparison

[phryneas]

Hi there,

I really like this plugin, but there's this one killer feature that I'm really missing for code reviews and that keeps me going back to gitkraken:

I'd love to mark multiple commits and view a consolidated diff of all those commits.

Could you please put that on your roadmap? :)

[mhutchie]

Currently you can can click on a commit, and then control/command click on any other commit, to view a consolidated diff of all changes between the selected commits (I use this for code reviews). Have you tried this?

If you have, and you're requesting something else, can you please describe a set of steps I could follow to better understand your request, and the advantage it offers over the steps mentioned above?

[phryneas]

I did, but I didn't really realize it worked, because it only highlighted the first and last commit, so I thought it would only include those two commits. Knowing what this actually does already helps a lot - thank you :+1:

Seeing as most other tools allow to select a range with the shift key and individual items with the control key, I guess I should change this feature request to that :grin:

Could you change the behaviour so that shift behaves like the current behaviour (and highlights the in-between commits optically) for consistency with other tools?

And additionally, it would be really great to be able to select individual commits using control.

[mhutchie]

When showing a commit comparison, the left side of the view does say "Displaying all changes from xxxx to yyyy" to explain the current behaviour.

Example commits:
D <- Head
C
B
A <- Initial Commit

In all the tools I've previously used, control clicking A, B & D (i.e. any number of commits) produces the same consolidated diff as control or shift clicking A & D. Because of this, I've never needed to select three (or more) specific commits, I just select the outside two. Do the tools you use behave differently? Is there an example where selecting three or more commits produces a different consolidated commit diff than just selecting the outside two?

[mhutchie]

The reason I didn't implement shift clicking is because it is visually ambiguous. Consider the example:

|
| C
| |
B |
| /
A

Shift clicking A & D implies "showing all differences between A & D". By highlighting all commits A, B, C & D in the UI from shift clicking, that would imply that the changes from A, B, C & D are included, when the diff is actually only including A, B & D (as C isn't between A & D from a Git ancestry perspective).

I find this behaviour in other tools (like SourceTree) misleading. For this reason I chose to only implement the control click user case, which from what I can see, is unambiguous.

What are your thoughts on this?

[phryneas]

Yup, I noticed that message after your previous comment, too :grin: I guess that optical indication of only two items being selected just overrode everything else in my vision :see_no_evil:

Tools that do this for git from the back of my mind would be IntelliJ/webStorm and GitKraken (actually it's quite hard to find git clients that allow to select multiple commits at all).

The general UI paradigm of "shift to select ranges, control to select individual items" would be most prominent in tools like windows explorer or finder, and is reflected by most list-selects that are native to Windows/OSX or even the browser multiselect - so I think from a UX standpoint it would be what most users expect.

[phryneas]

The reason I didn't implement shift clicking is because it is visually ambiguous. Consider the example:

|
| C
| |
B |
| /
A

Shift clicking A & D implies "showing all differences between A & D". By highlighting all commits A, B, C & D in the UI from shift clicking, that would imply that the changes from A, B, C & D are included, when the diff is actually only including A, B & D (as C isn't between A & D from a Git ancestry perspective).

I find this behaviour in other tools (like SourceTree) misleading. For this reason I chose to only implement the control click user case, which from what I can see, is unambiguous.

What are your thoughts on this?

Couldn't that just highlight the commits that are actually included, meaning selecting the range from A to D would only highlight A,B,D?

[phryneas]

Tools that do this for git from the back of my mind would be IntelliJ/webStorm and GitKraken (actually it's quite hard to find git clients that allow to select multiple commits at all).

Just wanted to clarify that: A use case here would be to highlight a range of 10 commits and deselect one commit in the middle that is just too messy and makes the other commits unreadable. These tools allow for that.

PS: I just did some tests: in gitKraken, selecting two commits gives you the diff between the two (highlighting all in-between only if they are on the same branch), and selecting 3+ commits gives you a view with all the changes of these commits consolidated.

[mhutchie]

Couldn't that just highlight the commits that are actually included, meaning selecting the range from A to D would only highlight A,B,D?

In the example:

|
D
|
| C
| |
B |
| /
A

If the rule is that all commits included in the comparison are highlighted, then:
Shift clicking C & E in this example would mean that commits A, B, C, D & E should be highlighted (as a common ancestry is used internally by git diff). I think most people would find it confusing if commits outside of the shift click range they selected where highlighted (even if it is what is occurring internally in git).

The constraint used by GitKraken of the commit range being on the same branch gets around this, but then the UI behaviour is inconsistent (which I have deliberately avoided).

---

Just wanted to clarify that: A use case here would be to highlight a range of 10 commits and deselect one commit in the middle that is just too messy and makes the other commits unreadable. These tools allow for that.

I just installed GitKraken, and can now see this in action.

The challenge with implementing this is that it is not built into git diff or git diff-tree (which only detect pairwise differences). From what I can see this would require the custom combining of patches of modified files for each included commit, to replicate git diff, git diff-tree output, and also produce the custom patched file contents required for each side of the Visual Studio Code Diff View. Although this is possible, I can't justify the significant time to implement this unless many people would frequently like to exclude specific commits (which I don't think is the case). _If others would, please like this post so I can keep track of interest._

[mhutchie]

This feature request has been left open for almost 11 months for others to express interest in this feature. As only one other Git Graph user has indicated they would like this functionality in this period, it seems to confirm my previous sentiment that this functionality wouldn't be frequently used by many users.

Note to users reading this in the future: If you'd like this functionality, please reply to this thread to express your interest. I'd happily re-open and add this feature if there was any indication it would be used by a decent number of users.