Git - support HEAD <> working tree changes in gutter

[TallGirlVanessa]

trafficstars

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.

[TallGirlVanessa]

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.

[TallGirlVanessa]

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.

[Nowaker]

@joaomoreno Can you review the proposed design above? What do you think? People seem to like it, given the number of upvotes it received.

[studgeek]

Would also be nice if one could do a diff between HEAD <> Working Tree as well. That would allow editing while seeing changes relative to HEAD (what I think users are practically asking for in #91065, #91274, #74149, #15785, and #33681). The various text editors listed above also support this as well (e.g. IntelliJ, Sublime, fugitive).

[studgeek]

I think easiest first step would be adding the ability to switch gutter bar diffs from current "Index <> Working Tree" to "HEAD <> Working Tree" and back. That is what @vlmphipps and @joaomoreno suggest early in the thread. It's also I believe what the other mentioned IDEs do.

The double gutter that @Nowaker mentioned is interesting, but I think its worth pointing out that it may be a bit trickier than it sounds on the surface. I assume it would be displaying Working Tree and would show gutters for both "HEAD <> Working Tree" and "Index <> Working Tree". The challenge is Working Set isn't always a superset of Index like that example image shows. HEAD, Index, and Working Tree can actually be very different. For example, it's possible for a file to exist in Working Tree and HEAD, but not exist in Index (or the reverse). I think it's still possible to do the double gutter diff, but each gutter diff ("HEAD <> Working Tree" and "Index <> Working Tree") would need to be its own column rather than mixed as shown in the proposed screenshot.

[ivanpu]

After ages of using other editors that show "HEAD <> Working Tree" in the gutter, this is the 2nd most annoying feature of VSCode for me. (The feature that most annoys me in VSCode comes from extension, that I plan to fork somewhen in the future, but I digress)

Gutter should show the user what has been changed in the files, and was not committed yet. Anything else is just confusing for anybody that have worked with any other editor.

At the minimum you should add the option to let us choose what we want to compare our working tree to (in the case that you insist to keep the comparison to the index).

edit: typo

[Nowaker]

+1 to the above comment.

would need to be its own column rather than mixed as shown in the proposed screenshot

@studgeek I see no problem with double column approach if warranted. Just saying most editors show a simplified view of things; maybe some sophisticated information gets lost but these are edge cases that aren't relevant for everyday use cases.

[mafjmafj]

| At the minimum you should add the option to let us choose what we want to compare our working tree to (in the case that you insist to keep the comparison to the index).

And this should not be just limited to Index and HEAD, but also base of your PR branch or any change in between. E.g. when you work on final clean-up of your patch queue.

[Nowaker]

Well said, @mafjmafj! That's an absolute minimum.

And I'd love to see the below (or some variation thereof) as an ultimate goal:

[mafjmafj]

Step back comment: We work these days with focus on changes and change sets. And we need a tool that not only supports that but makes it a central focus.

[jolammi]

Hi @lszomoru, regariding your self-assignment, can we expect to have this at some point in the near future?

[lszomoru]

@jolammi, the self-assignment was part of a bulk update due to a transfer of ownership of the SCM/git area.

[DanKaplanSES]

@joaomoreno said:

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?

While this is true, the current functionality is also confusing for other reasons:

[EDIT: unfortunately this 404s now. Hopefully the next paragraph paints the picture.]

In this case, one of the changes is staged in the index, the others are already committed. Which one is which?

---

I'm also confused about the state of this issue: is it waiting for someone to implement it, or are we still discussing whether this is a desired feature?

[ghost]

Is this change going to happen?

[Nowaker]

Looks like forgotten. VSCode is now focusing on AI, with little care given to the core features like this.

[ranger-ross]

This is still a wanted feature :pray:

[starball5]

Related on Stack Overflow: Can I make Visual Studio Code highlight staged changes?

[EdgarLip]

Hello , as the original top post suggested : by @TallGirlVanessa
this is must to have ... ( staged changes should be indicated !!! ) is this gonna happen ?

thanks

[canyone2015]

I don't understand how this necessary functionality is still not added.

[mgaineev]

Hi, sorry to mention you @kieferrm, just wanted someone from the VSCode team to see this. Many people think this is an important improvement, and we really hope you can plan it someday. Thank you.