Vscode: Git: support HEAD <> working tree changes in gutter

[vlmphipps]

Issue Type: Feature Request

I'd like to see staged changes as well as unstaged changes in the gutter. Currently, VS Code only shows unstaged changes, at least when using Git.

Unstaged changes:

Staged changes:

See https://stackoverflow.com/questions/48881124/can-i-make-visual-studio-code-highlight-staged-changes as well as https://github.com/eamodio/vscode-gitlens/issues/396 .

VS Code version: Code 1.28.0 (431ef9da3cf88a7e164f9d33bf62695e07c6c2a9, 2018-10-04T16:40:40.180Z)
OS version: Darwin x64 16.7.0

[vscodebot[bot]]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Git: Provide single shortcut for "Stage Changes"/"Unstage Changes" (#44592)
• [Feature Request] Add "Git: Stage/Unstage chages" to the file context menu (#53067)
• Feature Request - Git option to disable auto stage (#26185)
• Git: Support line staging (#9475)
• Unstaging ranges leaves out whitespace changes (#48268)
  

[joaomoreno]

When you're editing a file in git, there are three versions of it:

• HEAD
• Index
• Working tree

So, there are two possible diffs to show:

• HEAD <> Index
• Index <> Working Tree

We currently show gutter decorations for Index <> Working Tree. Since the file which is open in the editor is always Working Tree, it doesn't make any sense to show HEAD <> Index changes in the gutter, since none of those two files is Working Tree.

[vlmphipps]

I get what you're saying, and recognize that this probably won't be read on a closed issue 😅 But, IntelliJ manages to make this work. So I have a hard time accepting that the feature doesn't make sense!

I see a third diff you haven't mentioned, which is HEAD <> Working Tree. That's exactly what I'm looking for, and that's what IntelliJ does too.

[joaomoreno]

Actually, because IntelliJ manages to do this, they actually end up having a confusing experience.

In this case, one of the changes is staged in the index, the other isn't. Which one is which? Also, when a change in the index intersects a change in the working tree, what do you actually show?

We can think about supporting a setting which toggles the dirty diff decorations to HEAD <> Working Tree and backwards... I wonder if there's enough need for it tho.

[fabb]

I like how it works in IntelliJ: I often stage parts that I definitely want to commit, and to allow me to experiment with temporary changes and still have the ability to reset those without losing the staged changes. In the editor I still see changed lines and can quickly jump between them with "Ctrl+Alt+Shift+Up/Down" which allows for a very fluid editing experience.

[vlmphipps]

I have the same workflow as @fabb and would appreciate the toggle you mentioned @joaomoreno .

I agree there's ambiguity in the IDE in the approach I'm asking for. Speaking for myself, I only stage and commit from the command line, so ambiguity in the IDE between staged and unstaged doesn't bother me.

Here's the flow that led me to write this issue:

1. Make some changes
2. Test the changes
3. Stage those changes
4. Look over the working tree <> HEAD diff using the IDE
5. Do last minute cleanup while I'm going through the diff, deleting extra newlines, removing unused imports, resolving lint errors
6. Use the command line to double check my unstaged changes, to see whether I need to retest. If they're all trivial I can stage and continue. If they're not I need to test again.
7. Stage
8. Use the command line to look over what I staged
9. Commit

When I tried this flow with VSCode I got stuck at step 4 because all my changes were no longer visible!

[ilteris]

It would be great to see staged changes in a different color at least "when": "textCompareEditorVisible && isInDiffEditor". That way we know what we are staging when we stage part of changes.

[geoffdavis92]

@ilteris I agree. I can see adds, removals, changes, and even inline diffs; I feel like I shouldn't have to use another program just to see what is staged.

I don't even necessarily think it needs to have a separate color for staged changes (though that would be intuitive); for example, the GitGutter plugin for Sublime Text continues to show the status of lines even when they're staged, and defers the (un)staged status to the command line.

@joaomoreno an alternative example of the need for this is that when all changes of a file are staged, the file in VSCode looks the same as a file that is already committed.

[trkoch]

Adding some perspective, this is the default behavior in Atom and can be configured in Sublime Text.

[trkoch]

I can see adding an option might confuse some users (even when disabled by default), on the other hand it disrupts the workflow of all users actively (and consciously) using the index as a in-between area of changes. For example, a possible workflow is to add changes to the index when everything is working as expected and all tests are green, right before any cleanup refactoring.

@joaomoreno I tried to take a look at the source but lost track eventually. Could you provide some hints what kind of changes are needed?

[matklad]

I want to argue (pretty strongly, but lightheartedly) that IntelliJ behavior is the right default here.

Actually, because IntelliJ manages to do this, they actually end up having a confusing experience.
In this case, one of the changes is staged in the index, the other isn't. Which one is which?

Note that you are only interested about "what's in the index", when you are making a commit. That is, this is a valuable info to show in the commit dialog.

When you are just hacking and making changes, you don't really care about what's in the index, you need to know which changes have you applied.

So, IntelliJ does (roughly) show what's in the index in the commit dialog:

Now, one can argue that IntelliJ is not a pinnacle of VCS integration design, however Emacs obviously is (/s). And Emacs (diff-hl and Magit) works exactly as described:

In the editor gutter, we see what is changed relative to HEAD. In the commit dialog, we clearly see whats in the index, and what's not in the index.

[Nowaker]

Maybe we should we should have another gutter indicator for changes that are staged? (after having been git added) Example: stripes.

Please note this is a terrible mspaint (and specifically, kolourpaint) job but it shows the idea.