New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Git status in File Explorer #178

Closed
ozsay opened this Issue Nov 19, 2015 · 247 comments

Comments

@ozsay

ozsay commented Nov 19, 2015

Similar to what atom provides in the project explorer:

  1. New files are displayed green.
  2. Modified are displayed yellow/orange.
  3. Ignored files are displayed transparent-ish.

Thanks

@joaomoreno joaomoreno changed the title from Feature request: Files status highlight according to their source control status to Git status in File Explorer Nov 19, 2015

@joaomoreno joaomoreno self-assigned this Nov 19, 2015

@egamma egamma modified the milestone: Backlog Dec 10, 2015

@waderyan

This comment has been minimized.

Show comment
Hide comment
@waderyan

waderyan Dec 16, 2015

Contributor
  • 1
Contributor

waderyan commented Dec 16, 2015

  • 1
@csinco

This comment has been minimized.

Show comment
Hide comment
@csinco

csinco Dec 16, 2015

Would be cool if this was exposed as an extension in some way. I worry that in some cases, the tree can be a bit polluted with color and look like a Christmas tree. Or if not, at least have the option to toggle it on and off.

csinco commented Dec 16, 2015

Would be cool if this was exposed as an extension in some way. I worry that in some cases, the tree can be a bit polluted with color and look like a Christmas tree. Or if not, at least have the option to toggle it on and off.

@waderyan

This comment has been minimized.

Show comment
Hide comment
@waderyan

waderyan Dec 16, 2015

Contributor

Yes I agree. I created a separate issue to have this exposed in extension API (see #1394).

Contributor

waderyan commented Dec 16, 2015

Yes I agree. I created a separate issue to have this exposed in extension API (see #1394).

@timc13

This comment has been minimized.

Show comment
Hide comment
@timc13

timc13 commented Mar 12, 2016

+1

@bpasero bpasero self-assigned this Mar 30, 2016

@Krisa

This comment has been minimized.

Show comment
Hide comment
@Krisa

Krisa Apr 20, 2016

Would love that too. The Git tab is very handy but this is for another purpose - having colors like in Atom would be very complimentary to see at a glance what's changed and where (with the color propagating automatically up to the top directory). That's probably the feature I miss the most from Atom.

Usually, you don't have 10s or 100s of modified files uncommitted, so it's unlikely to look like a Christmas tree :)

Krisa commented Apr 20, 2016

Would love that too. The Git tab is very handy but this is for another purpose - having colors like in Atom would be very complimentary to see at a glance what's changed and where (with the color propagating automatically up to the top directory). That's probably the feature I miss the most from Atom.

Usually, you don't have 10s or 100s of modified files uncommitted, so it's unlikely to look like a Christmas tree :)

@dend

This comment has been minimized.

Show comment
Hide comment
@dend

dend Jul 21, 2016

So it looks like the PR for this was closed. @bpasero @joaomoreno - any updates on the status of this work?

dend commented Jul 21, 2016

So it looks like the PR for this was closed. @bpasero @joaomoreno - any updates on the status of this work?

@JohhnyP

This comment has been minimized.

Show comment
Hide comment
@JohhnyP

JohhnyP commented Jul 22, 2016

Check this #8462

@joaomoreno

This comment has been minimized.

Show comment
Hide comment
@joaomoreno

joaomoreno Jul 22, 2016

Member

No updates...

Member

joaomoreno commented Jul 22, 2016

No updates...

@bpasero

This comment has been minimized.

Show comment
Hide comment
@bpasero

bpasero Aug 5, 2016

Member

Thanks so much for your interest in this issue! It is currently assigned to the backlog. Every month we pick items from the backlog to plan for the current iteration. Please see https://github.com/Microsoft/vscode/wiki/Issue-Tracking#planning for more information.

Since we are a small team of developers, there is only so many feature requests and issues we can work on for one milestone. Nevertheless we always welcome pull requests and are happy to accept them if they meet our quality standards.

Member

bpasero commented Aug 5, 2016

Thanks so much for your interest in this issue! It is currently assigned to the backlog. Every month we pick items from the backlog to plan for the current iteration. Please see https://github.com/Microsoft/vscode/wiki/Issue-Tracking#planning for more information.

Since we are a small team of developers, there is only so many feature requests and issues we can work on for one milestone. Nevertheless we always welcome pull requests and are happy to accept them if they meet our quality standards.

@leaxoy

This comment has been minimized.

Show comment
Hide comment
@leaxoy

leaxoy commented Oct 13, 2016

+1

@drew-r

This comment has been minimized.

Show comment
Hide comment
@drew-r

drew-r commented Oct 17, 2016

+1

@jayjun

This comment has been minimized.

Show comment
Hide comment
@jayjun

jayjun Oct 25, 2017

Contributor

@WadeShuler @jrieken The current SCM viewlet (1.17.2) marks an untracked file with a grey U, and an added file with a green A. git status shows added (staged) files in ANSI green.

So I understand the confusion with a green U for an untracked file. I also foresee my eyes hurting from green Us mixing with green As.

Atom colours both untracked and staged new files as green, and Xcode marks added files as A as long as it’s a new file. Both of which never bothered me in the slightest (but a green U does).

So I’ll all for using green As for untracked and staged new files.

Contributor

jayjun commented Oct 25, 2017

@WadeShuler @jrieken The current SCM viewlet (1.17.2) marks an untracked file with a grey U, and an added file with a green A. git status shows added (staged) files in ANSI green.

So I understand the confusion with a green U for an untracked file. I also foresee my eyes hurting from green Us mixing with green As.

Atom colours both untracked and staged new files as green, and Xcode marks added files as A as long as it’s a new file. Both of which never bothered me in the slightest (but a green U does).

So I’ll all for using green As for untracked and staged new files.

@jrieken

This comment has been minimized.

Show comment
Hide comment
@jrieken

jrieken Oct 25, 2017

Member

Lets continue the 'U' vs 'A' vs '?' discussion in #36912. Thanks.

Member

jrieken commented Oct 25, 2017

Lets continue the 'U' vs 'A' vs '?' discussion in #36912. Thanks.

@kleber-swf

This comment has been minimized.

Show comment
Hide comment
@kleber-swf

kleber-swf Oct 25, 2017

I agree. I think its better to continue with the letters used in the interface today. I don't like the 'U' too but I think this is kinda out of the scope of this feature request. If this changed, it should change in the entire program.

kleber-swf commented Oct 25, 2017

I agree. I think its better to continue with the letters used in the interface today. I don't like the 'U' too but I think this is kinda out of the scope of this feature request. If this changed, it should change in the entire program.

@jez9999

This comment has been minimized.

Show comment
Hide comment
@jez9999

jez9999 Oct 26, 2017

OK this is a huge thread and I only have time to skimread it, so I'll just say here: I hope there is a setting to disable this. I prefer all the filenames in the same colour and when I need to see their status I type git status. :-)

jez9999 commented Oct 26, 2017

OK this is a huge thread and I only have time to skimread it, so I'll just say here: I hope there is a setting to disable this. I prefer all the filenames in the same colour and when I need to see their status I type git status. :-)

@jrieken jrieken referenced this issue Oct 30, 2017

Closed

Test git status in explorer #37159

2 of 2 tasks complete
@timscott

This comment has been minimized.

Show comment
Hide comment
@timscott

timscott Nov 1, 2017

Is this product abandoned? Seems to be.

timscott commented Nov 1, 2017

Is this product abandoned? Seems to be.

@Shurelia

This comment has been minimized.

Show comment
Hide comment
@Shurelia

Shurelia Nov 1, 2017

Currently, list.activeSelectionForeground seems to take precedence over the git status styling, so the git status colors can't be seen the selected file. I find this information useful to have, even on the currently selected file. Any chance the git status styling can take priority when explorer.decorations.colors is true?
This behavior was observed on insiders 1.18 8dfa696.

Shurelia commented Nov 1, 2017

Currently, list.activeSelectionForeground seems to take precedence over the git status styling, so the git status colors can't be seen the selected file. I find this information useful to have, even on the currently selected file. Any chance the git status styling can take priority when explorer.decorations.colors is true?
This behavior was observed on insiders 1.18 8dfa696.

@vvs

This comment has been minimized.

Show comment
Hide comment
@vvs

vvs Nov 1, 2017

Currently, list.activeSelectionForeground seems to take precedence over the git status styling, so the git status colors can't be seen the selected file.

Indeed, same here on the very latest insiders (just updated). When I click on the file name in the project tree, the color of the file entry is changed (say, from yellow/modified to neutral). I also think that this is a rather confusing behavior. The color of the file should not change when user clicks on the file.

Btw, the same problem with the open files list, when you click on the file there, the git status color is replaced by the neutral selection color.

vvs commented Nov 1, 2017

Currently, list.activeSelectionForeground seems to take precedence over the git status styling, so the git status colors can't be seen the selected file.

Indeed, same here on the very latest insiders (just updated). When I click on the file name in the project tree, the color of the file entry is changed (say, from yellow/modified to neutral). I also think that this is a rather confusing behavior. The color of the file should not change when user clicks on the file.

Btw, the same problem with the open files list, when you click on the file there, the git status color is replaced by the neutral selection color.

@jrieken

This comment has been minimized.

Show comment
Hide comment
@jrieken

jrieken Nov 1, 2017

Member

Btw, the same problem with the open files list, when you click on the file there, the git status color is replaced by the neutral selection color.

Well, it was done on purpose because the selection-foreground color often conflicts with the decoration colors. Adding more colors, like git.untrackedSelectedForeground and git.untrackedFocusedForeground didn't seem very appealing to us. Therefore we let the selection color win when an item is selected and has focus.

Member

jrieken commented Nov 1, 2017

Btw, the same problem with the open files list, when you click on the file there, the git status color is replaced by the neutral selection color.

Well, it was done on purpose because the selection-foreground color often conflicts with the decoration colors. Adding more colors, like git.untrackedSelectedForeground and git.untrackedFocusedForeground didn't seem very appealing to us. Therefore we let the selection color win when an item is selected and has focus.

@WadeShuler

This comment has been minimized.

Show comment
Hide comment
@WadeShuler

WadeShuler Nov 1, 2017

Atom doesn't seem to have a problem with it....

atom-selected-color

There is no need for new settings... The themes will update to accommodate if the selected item background color interferes. Those who fail to do so, the community will decide to not use those themes.

I haven't checked, but I hope the "badges" (ie: U, M), aren't still svg files. They should just be raw text that can be styled/colored.

Honestly, VSCode should have just went with stylesheets for these things instead of clunky config settings. It overcomplicated a rather simple process.

WadeShuler commented Nov 1, 2017

Atom doesn't seem to have a problem with it....

atom-selected-color

There is no need for new settings... The themes will update to accommodate if the selected item background color interferes. Those who fail to do so, the community will decide to not use those themes.

I haven't checked, but I hope the "badges" (ie: U, M), aren't still svg files. They should just be raw text that can be styled/colored.

Honestly, VSCode should have just went with stylesheets for these things instead of clunky config settings. It overcomplicated a rather simple process.

@jrieken

This comment has been minimized.

Show comment
Hide comment
@jrieken

jrieken Nov 1, 2017

Member

@WadeShuler There is selection and focus and because I see an editor cursor in your screen shot I believe your item is only selected, not focused. In fact I don't see a difference in Atom between selected and focused. This is how it's in VS Code

selected but not focused

screen shot 2017-11-01 at 16 16 35

selected and focused
screen shot 2017-11-01 at 16 16 47

Member

jrieken commented Nov 1, 2017

@WadeShuler There is selection and focus and because I see an editor cursor in your screen shot I believe your item is only selected, not focused. In fact I don't see a difference in Atom between selected and focused. This is how it's in VS Code

selected but not focused

screen shot 2017-11-01 at 16 16 35

selected and focused
screen shot 2017-11-01 at 16 16 47

@WadeShuler

This comment has been minimized.

Show comment
Hide comment
@WadeShuler

WadeShuler Nov 1, 2017

@jrieken I have double checked, and in my Atom, selected vs focused produce the same result. It never loses the yellow font color on the left file explorer window. In your 2nd screenshot, the red color is lost from test.foo, which is the issue.

I have tried the default dark and light Atom themes, as well as about 3 other themes. My default (as you see in my SS) is Seti (both UI and theme). I am unable to get Atom to drop the yellow color from the file explorer, no matter what I do. Atom version 1.21.2.

Selected
selected

Selected & Focused
selected-focused

Out of the box, VS Code should preserve the git status color regardless of selected or focused states.

If your issue is themes, it isn't your problem. That is the responsibility of the theme developers to update and accommodate.


On a side note: I haven't checked out the latest insiders or viewed the code, but the git ignored files should use opacity not a font color so it is always x darker than regular files, regardless of their color.

WadeShuler commented Nov 1, 2017

@jrieken I have double checked, and in my Atom, selected vs focused produce the same result. It never loses the yellow font color on the left file explorer window. In your 2nd screenshot, the red color is lost from test.foo, which is the issue.

I have tried the default dark and light Atom themes, as well as about 3 other themes. My default (as you see in my SS) is Seti (both UI and theme). I am unable to get Atom to drop the yellow color from the file explorer, no matter what I do. Atom version 1.21.2.

Selected
selected

Selected & Focused
selected-focused

Out of the box, VS Code should preserve the git status color regardless of selected or focused states.

If your issue is themes, it isn't your problem. That is the responsibility of the theme developers to update and accommodate.


On a side note: I haven't checked out the latest insiders or viewed the code, but the git ignored files should use opacity not a font color so it is always x darker than regular files, regardless of their color.

@fernandofleury

This comment has been minimized.

Show comment
Hide comment
@fernandofleury

fernandofleury Nov 3, 2017

@WadeShuler thanks for your feedback on how theme managers should handle their business! How dare VSCode team provide an API to help them doing that? Those lazy developers!

fernandofleury commented Nov 3, 2017

@WadeShuler thanks for your feedback on how theme managers should handle their business! How dare VSCode team provide an API to help them doing that? Those lazy developers!

@WadeShuler

This comment has been minimized.

Show comment
Hide comment
@WadeShuler

WadeShuler Nov 3, 2017

@fernandofleury Nobody said anything about not providing theme managers an API to manage it. My post said nothing of the sort. So your snarky comment, is simply invalid and unwarranted.

@jrieken said:

Well, it was done on purpose because the selection-foreground color often conflicts with the decoration colors.

I said:

If your issue is themes, it isn't your problem. That is the responsibility of the theme developers to update and accommodate.

The issue would be a conflict between the foreground (actually, it's a background color) color of the file/folder tree item (normal, selected, focused), and the font color choices for the various git statuses.

This would be the responsibility of theme developers. They should choose both the foreground colors of the items in the tree and the font colors for the various git statuses so that they don't conflict.

For example: A theme developer has ThemeX and his font color for the items in the explorer file tree is yellow. Well, his default font color would conflict with the default yellow git status color. You wouldn't be able to tell which files are modified anymore. So this would be the responsibility of the theme developers! -- The same is for the background color for selected/selected-focused items in the explorer file tree vs the font colors of the git statuses.

WadeShuler commented Nov 3, 2017

@fernandofleury Nobody said anything about not providing theme managers an API to manage it. My post said nothing of the sort. So your snarky comment, is simply invalid and unwarranted.

@jrieken said:

Well, it was done on purpose because the selection-foreground color often conflicts with the decoration colors.

I said:

If your issue is themes, it isn't your problem. That is the responsibility of the theme developers to update and accommodate.

The issue would be a conflict between the foreground (actually, it's a background color) color of the file/folder tree item (normal, selected, focused), and the font color choices for the various git statuses.

This would be the responsibility of theme developers. They should choose both the foreground colors of the items in the tree and the font colors for the various git statuses so that they don't conflict.

For example: A theme developer has ThemeX and his font color for the items in the explorer file tree is yellow. Well, his default font color would conflict with the default yellow git status color. You wouldn't be able to tell which files are modified anymore. So this would be the responsibility of the theme developers! -- The same is for the background color for selected/selected-focused items in the explorer file tree vs the font colors of the git statuses.

@IljaDaderko

This comment has been minimized.

Show comment
Hide comment
@IljaDaderko

IljaDaderko Nov 8, 2017

Is this postponed now?

IljaDaderko commented Nov 8, 2017

Is this postponed now?

@ghiscoding

This comment has been minimized.

Show comment
Hide comment
@ghiscoding

ghiscoding Nov 8, 2017

@IljaDaderko I don't think so since it shows up in the upcoming Release Note v1.18 of the next Stable version. The question might be more, will this be closed or is there still more work to be done?

ghiscoding commented Nov 8, 2017

@IljaDaderko I don't think so since it shows up in the upcoming Release Note v1.18 of the next Stable version. The question might be more, will this be closed or is there still more work to be done?

@wilsenhc

This comment has been minimized.

Show comment
Hide comment
@wilsenhc

wilsenhc Nov 9, 2017

@IljaDaderko VSCode v1.18 is already out and it includes the changes discussed here.

wilsenhc commented Nov 9, 2017

@IljaDaderko VSCode v1.18 is already out and it includes the changes discussed here.

@Shurelia

This comment has been minimized.

Show comment
Hide comment
@Shurelia

Shurelia Nov 9, 2017

Are ignored file colors supposed to be a part of the v1.18 update? The docs say gitDecoration.ignoredResourceForeground can be used to color ignored files, but so far I haven't been able to see that affect anything. Modified/untracked coloring works great though. This is on stable 1.18.0, windows.

Shurelia commented Nov 9, 2017

Are ignored file colors supposed to be a part of the v1.18 update? The docs say gitDecoration.ignoredResourceForeground can be used to color ignored files, but so far I haven't been able to see that affect anything. Modified/untracked coloring works great though. This is on stable 1.18.0, windows.

@MrCroft

This comment has been minimized.

Show comment
Hide comment
@MrCroft

MrCroft Nov 9, 2017

Same here (about ignored color). Hasn't been working for me either, since this whole Git implementation started. Using Insiders.
All that gitDecoration.ignoredResourceForeground does is ignore ignored files from coloring :)

MrCroft commented Nov 9, 2017

Same here (about ignored color). Hasn't been working for me either, since this whole Git implementation started. Using Insiders.
All that gitDecoration.ignoredResourceForeground does is ignore ignored files from coloring :)

@arxpoetica

This comment has been minimized.

Show comment
Hide comment
@arxpoetica

arxpoetica Nov 9, 2017

It's working for me and it looks SPECTACULAR.

arxpoetica commented Nov 9, 2017

It's working for me and it looks SPECTACULAR.

@VladBozhinovski

This comment has been minimized.

Show comment
Hide comment
@VladBozhinovski

VladBozhinovski Nov 9, 2017

Finally it's here 🥇

VladBozhinovski commented Nov 9, 2017

Finally it's here 🥇

@MrCroft

This comment has been minimized.

Show comment
Hide comment
@MrCroft

MrCroft Nov 9, 2017

@arxpoetica This is what I get:
image

How can it work for some and not for others, I don't get it. It's just that one setting gitDecoration.ignoredResourceForeground
Am I the only one it doesn't work for? Really no one else? :) Oh, and @Shurelia
Has anybody else (us, users) actually tested setting the ignored color before saying it works?

OS: Windows 10 PRO (1709)
VSCode: 1.19.0-insider (just updated earlier)
Same on my work laptop and home desktop.

MrCroft commented Nov 9, 2017

@arxpoetica This is what I get:
image

How can it work for some and not for others, I don't get it. It's just that one setting gitDecoration.ignoredResourceForeground
Am I the only one it doesn't work for? Really no one else? :) Oh, and @Shurelia
Has anybody else (us, users) actually tested setting the ignored color before saying it works?

OS: Windows 10 PRO (1709)
VSCode: 1.19.0-insider (just updated earlier)
Same on my work laptop and home desktop.

@nkkollaw

This comment has been minimized.

Show comment
Hide comment
@nkkollaw

nkkollaw Nov 9, 2017

Is it in Insiders? How can I use it?

Congrats, everyone!

nkkollaw commented Nov 9, 2017

Is it in Insiders? How can I use it?

Congrats, everyone!

@jrieken

This comment has been minimized.

Show comment
Hide comment
@jrieken

jrieken Nov 9, 2017

Member

@nkkollaw In both 😎 insiders and stable (1.18)

Member

jrieken commented Nov 9, 2017

@nkkollaw In both 😎 insiders and stable (1.18)

@jrieken

This comment has been minimized.

Show comment
Hide comment
@jrieken

jrieken Nov 9, 2017

Member

@MrCroft Please discuss git-ignore issues here: #37857

Member

jrieken commented Nov 9, 2017

@MrCroft Please discuss git-ignore issues here: #37857

@jrieken

This comment has been minimized.

Show comment
Hide comment
@jrieken

jrieken Nov 9, 2017

Member

As we have shipped this feature in our latest stable build it's time to close and lock this issue. Please create new issues for topic discussions and bug reports. Issues around this area are tagged with the file-decorations-label.

Everyone, thanks for the great and continued feedback that made this feature what it is!

To summarise and repeat my previous comment.

screen shot 2017-10-24 at 19 51 36 2

A couple of things

  • By default there is a combination of color and bagde.
    • enable/disable icons with: "explorer.decorations.badges": true|false
    • enable/disable colors with "explorer.decorations.colors": true|false
  • Colors show in the file tree, the open editors section, and in the SCM viewlet
  • There are three colors to begin with. You can customise them in the workbench.colorCustomizations-setting. The colors are gitDecoration.modifiedResourceForeground,
    gitDecoration.deletedResourceForeground,
    gitDecoration.untrackedResourceForeground,
    gitDecoration.ignoredResourceForeground, and
    gitDecoration.conflictingResourceForeground
Member

jrieken commented Nov 9, 2017

As we have shipped this feature in our latest stable build it's time to close and lock this issue. Please create new issues for topic discussions and bug reports. Issues around this area are tagged with the file-decorations-label.

Everyone, thanks for the great and continued feedback that made this feature what it is!

To summarise and repeat my previous comment.

screen shot 2017-10-24 at 19 51 36 2

A couple of things

  • By default there is a combination of color and bagde.
    • enable/disable icons with: "explorer.decorations.badges": true|false
    • enable/disable colors with "explorer.decorations.colors": true|false
  • Colors show in the file tree, the open editors section, and in the SCM viewlet
  • There are three colors to begin with. You can customise them in the workbench.colorCustomizations-setting. The colors are gitDecoration.modifiedResourceForeground,
    gitDecoration.deletedResourceForeground,
    gitDecoration.untrackedResourceForeground,
    gitDecoration.ignoredResourceForeground, and
    gitDecoration.conflictingResourceForeground

@jrieken jrieken closed this Nov 9, 2017

@Microsoft Microsoft locked and limited conversation to collaborators Nov 9, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.