Skip to content
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
Closed

Git status in File Explorer #178

ozsay opened this issue Nov 19, 2015 · 247 comments
Assignees
Labels
feature-request Request for new features or functionality file-decorations file-explorer Explorer widget issues git GIT issues
Milestone

Comments

@ozsay
Copy link

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 added the feature-request Request for new features or functionality label Nov 19, 2015
@joaomoreno joaomoreno changed the title Feature request: Files status highlight according to their source control status 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
Copy link

  • 1

@csinco
Copy link

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
Copy link

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

@bpasero bpasero added file-explorer Explorer widget issues git GIT issues labels Dec 18, 2015
@timc13
Copy link

timc13 commented Mar 12, 2016

+1

@0cv
Copy link

0cv 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
Copy link

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
Copy link

JohhnyP commented Jul 22, 2016

Check this #8462

@joaomoreno
Copy link
Member

No updates...

@bpasero
Copy link
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
Copy link

leaxoy commented Oct 13, 2016

+1

1 similar comment
@drew-r
Copy link

drew-r commented Oct 17, 2016

+1

@jayjun
Copy link
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
Copy link
Member

jrieken commented Oct 25, 2017

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

@kleber-swf
Copy link

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
Copy link

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. :-)

@timscott
Copy link

timscott commented Nov 1, 2017

Is this product abandoned? Seems to be.

@emily-curry
Copy link

emily-curry 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
Copy link

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
Copy link
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.

@CyberPunkCodes
Copy link

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
Copy link
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

@CyberPunkCodes
Copy link

@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
Copy link

@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!

@CyberPunkCodes
Copy link

@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.

@xzilja
Copy link

xzilja commented Nov 8, 2017

Is this postponed now?

@ghiscoding
Copy link

@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
Copy link

wilsenhc commented Nov 9, 2017

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

@emily-curry
Copy link

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.

@NgxDev
Copy link

NgxDev 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
Copy link

It's working for me and it looks SPECTACULAR.

@SETI-At-Home
Copy link

Finally it's here 🥇

@NgxDev
Copy link

NgxDev 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
Copy link

nkkollaw commented Nov 9, 2017

Is it in Insiders? How can I use it?

Congrats, everyone!

@jrieken
Copy link
Member

jrieken commented Nov 9, 2017

@nkkollaw In both 😎 insiders and stable (1.18)

@jrieken
Copy link
Member

jrieken commented Nov 9, 2017

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

@jrieken
Copy link
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 as completed 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.
Labels
feature-request Request for new features or functionality file-decorations file-explorer Explorer widget issues git GIT issues
Projects
None yet
Development

No branches or pull requests