• 1

如果以某种方式将其作为扩展公开会很酷。 我担心在某些情况下，这棵树可能会被颜色污染，看起来像一棵圣诞树。 或者，如果没有，至少可以选择打开和关闭它。

是的我同意。 我创建了一个单独的问题，以便在扩展 API 中公开它（参见 #1394）。

+1

也会喜欢的。 Git 选项卡非常方便，但这是出于另一个目的 - 拥有像 Atom 中的颜色将非常有用，可以一目了然地看到更改的内容和位置（颜色会自动传播到顶级目录）。 这可能是我最怀念 Atom 的功能。

通常，您不会有 10 或 100 个未提交的修改文件，因此它不太可能看起来像圣诞树 :)

所以看起来这个 PR 已经关闭了。 @bpassero @joaomoreno - 这项工作的状态有什么更新吗？

检查这个https://github.com/Microsoft/vscode/pull/8462

没有更新...

非常感谢您对此问题的关注！ 它目前已分配给积压工作。 每个月我们都会从 backlog 中挑选项目来计划当前的迭代。 请参阅https://github.com/Microsoft/vscode/wiki/Issue-Tracking#planning了解更多信息。

由于我们是一个小型开发人员团队，因此我们可以为一个里程碑处理的功能请求和问题非常有限。 尽管如此，我们始终欢迎拉取请求，如果它们符合我们的质量标准，我们很乐意接受它们。

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

请停止写+1 。 它会向问题中的每个人发送电子邮件。 在第一条评论上使用表情符号反应。

+1

嗨，您有关于此功能请求的任何消息吗？ 我今天开始使用 vscode，我已经爱上了，但我真的很想念表明变化的颜色
祝贺你的工作

+1

在执行此操作时，请考虑206

我添加了一些屏幕截图以提供帮助：

原子默认值：

VSCode 默认值：

+1

+1

这将非常有用。

已经能够修改文件和图标在文件树中的列出方式。
这个扩展做到了
https://github.com/robertohuertasm/vscode-icons。

但是它不会为文件名着色

+1

+1

有什么变化吗？ 此功能阻止我离开 Atom。 :(

我刚刚离开 Atom，因为在 VSC 中的性能感觉要好得多。 然而，这是我在 VSC 中怀念的豪华功能。

+1

我认为将其作为内置设置（例如git.colorExplorer ）而不是扩展名会很好。

@arkon有没有这样的扩展名？ 我找不到任何。

很可能文件资源管理器没有 API 来根据
git 更改。 延期对我来说没问题。

在星期五，2017年2月3日，拉胡尔07:52 [email protected]写道：

@arkon https://github.com/arkon有没有这样的扩展？ 我不能
找到任何。

—
您收到此消息是因为您订阅了此线程。
直接回复本邮件，在GitHub上查看
https://github.com/Microsoft/vscode/issues/178#issuecomment-277177373 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AEQJ1eoLm7Sp59a2hE0tIFQnb0Q5cJnSks5rYs6tgaJpZM4GlYyH
.

@rahulnever2far不，这只是一个建议，因为之前有人建议它可以作为扩展 API 公开（我想这也可以）。

最近决定继续使用 VSCode，我真的很想念这个功能

请加。 尝试从 Atom 跳过时会增加生产力的摩擦。

@KozhokarAlex @bhudgens和其他人：单击第一篇文章中的竖起大拇指图标，向开发人员显示您正在请求此功能。 他们通过竖起大拇指对问题进行排序，以确定哪些功能请求是最受欢迎的。

从这种问题排序中可以看出，这个问题是目前第三大要求的功能。

竖起大拇指。 最近从 Atom 过来..希望很快能在 VSCode 中看到它！

啊谢谢@joaomoreno！

还请向 QuickOpen 添加相同的着色/qit 状态，而不仅仅是 FileExplorer。
通过这种方式，可以根据已更改的文件在视觉上过滤打开的文件。

这是怎么回事？ 为什么维护者不合并@joaomoreno PR ？ 有我们现在可以使用的插件吗？ 这只是愚蠢的计划

@SOSANA不确定您所说的 PR 是什么意思，您指的是哪个 PR？

2824开门来修这个，所以再耐心一点。

@SOSANA 那是一个问题，而不是 PR 🤣

+1 这个功能对生产力来说是惊人的

+1

@publiclass1 @hevans90 ，...（插入所有其他评论 +1 的人）...，请不要发表关于您有多想要此功能的评论。 这就是 GitHub 添加表情符号反应的原因。 只需赞一下原始评论。 这样我就可以恢复使用电子邮件通知的目的（随时了解此问题的进展情况，而不是世界上的任何人都想要这个）。 很抱歉大家也向你发送垃圾邮件。 我真诚地希望更多的人能够学会停止+1问题。

+1

我使用 PhpStorm 但更愿意使用 VS Code 来处理所有事情。 我目前使用尽可能多的 VS Code 窗口。 你能否最终选择这个着色系统，因为我更喜欢/知道 PhpStorm 的颜色。 以供参考：

黑色 - 最新 - 文件未更改。
灰色 - 已删除 - 计划从存储库中删除文件。
蓝色 - 已修改 - 自上次同步以来文件已更改。
绿色 - 已添加 - 计划将文件添加到存储库。
棕色 - 未知 - 文件存在于本地，但不在存储库中，且未安排添加。

等通过https://www.jetbrains.com/help/phpstorm/2016.3/file-status-highlights.html 。 你们摇滚，谢谢。

和

• 与冲突合并的文件显示为红色，

将冲突与其他人区分开来非常方便

+1 必须在 Git <> Explorer 视图之间来回切换是非常低效的。

理想情况下，还可以将变更集视为位于我们打开文件的顶部的组，以及按颜色可视化的嵌套变更树（如上面的@abdonrd所示）。

来一个家伙，只是停止+1。

请在第一个帖子上竖起大拇指。

我有一个有趣的用例和参数来制作一个通用 API，它允许插件为单个文件和文件夹着色：

文件/文件夹老化类似于Trello 老化加电- 我希望长时间未触及的文件和文件夹（根据 git 历史判断）淡出，以便“工作集”更加清晰和清晰更容易找到。

为什么：我有大量的小项目（想想一堆用于分析报告的脚本），其中 90+% 的工作不会再被触及（但我不能将旧的东西移到子文件夹，因为它会破坏很多指向回购的链接）。

如果有一个用于为树项着色的 API 端点，我可以编写一个插件来读取 git 日志并根据一组规则为每个文件/文件夹着色。

那么它呢，是否还有允许为此创建扩展的 API，或者这将作为集成功能实现？

这事有进一步更新吗？

+1

+1

+1

你们能不能停止 +1 和向我们的邮件收件箱发送垃圾邮件？？？

它根本没有任何意义。

+1 到没有垃圾邮件 xD

protip：过滤掉来自 github 的消息，其中 body 等于/matches/lolwuts "+1"

你不能阻止这些人。

@jmbelloteau正如@fredrikaverpil之前在评论中所说的那样，VSCode 问题按对原始评论的点赞数排序。 因此，评论“+1”而不是对第一条评论添加反应确实是垃圾邮件，因为这不是提供反馈的正确方式，只会向所有人发送无用的电子邮件。 与添加反应相反，它甚至不会被考虑在内。

+1

我在 Webstorm 中也很习惯这个 :D。 但正如我所见，这可能迟早会被开发出来。 这是来自 Webstorm 的屏幕截图以获取灵感（在@abdonrd 之后）：

啊，未跟踪的文件也显示为红色！

+1

今天第一次尝试了 VS 代码（来自 Atom），我搜索的第一个扩展是在资源管理器视图中突出显示的“git status”。 “源代码控制”选项卡本身非常好，但是突出显示文件夹/文件可以让我快速导航到我正在工作的组件，而不必总是保持我的目录树处于展开状态（对于倾向于有更深的嵌套结构）。

理想情况下，如果颜色能够单独修改，那就太好了。

{
    git.newFileColor: 'green',
    git.changedFileColor: 'yellow',
    git.untrackedFileColor: 'blue',
    git.ignoredFileColor: 'gray,
    git.mergeConflictFileColor: 'red'
}

+1

我一直在寻找一个好的应用程序来提醒我喝水。
然后，我意识到我订阅了这个线程。
保持 +1 来的家伙，他们不再没用了🚰

@mmazzarolo
为什么需要提醒喝水？ 渴了喝水还不够吗？

无论如何，请停止 +1-ing。 我相信开发人员已经意识到这一点，并且会在更新时发布。

@pohmelie这是一个有效的选择，谢谢！

+1

这些+1 人有问题吗？

好主意，@davidhu2000！ 支持像git.ignoredFileColor: '#333333'这样的十六进制颜色也很好。

JetBrains 在这里使用了一个很好的类型和颜色列表： https :

+1 提高人们对该功能的需求程度的认识

我不使用 VS Code 的唯一原因。 太糟糕了 ：（

任何人都知道代码库中的哪里可以开始实现这一点？ 我想试一试。

@admosity 去年有人已经提交了一个被拒绝的拉取请求： https :

2824 在上面的某个地方被提到作为一个拦截器，它已经被合并了一段时间。 我会查看那里的更改，以确保它按照 VS-Team 的要求实施。

@AndreasGassmann太棒了！ 我来看看。

最后一个关键功能阻止我切换到 vs 代码

加入这个功能后，我会改成vscode

我订阅了这个问题，因为我想知道什么时候取得了一些进展。
每个人都知道这个功能有多受欢迎，现在是

如果你真的，真的想要这个功能，只需upvote第一条评论，避免添加重复评论。

对于觉得这个功能有必要切换到VS Code的人。 我可以说这是我从 Atom 切换时错过的第一个功能，但 IMO 为这个很棒的 IDE 付出的代价很小。
更重要的是，上周我不得不在 Atom 中做一些工作，我真的很想念 VS Code 的 git 视图。

@waderyan这是一个从原子转移的交易破坏者。

是的，请！

+1

+1

+1

我做了一个非常丑陋的 hack，它通过修改workbench.main.js并根据git status输出注入 CSS 来实现此功能。 如果您不介意挖掘 VS Code 内部文件并让您的 VS Code 每 5 秒执行一次git status ，请看一看。

https://github.com/karabaja4/vscode-explorer-git-status

2017 年 6 月 28 日更新：修复了重新打开项目时插件无法加载的错误。
2017 年 6 月 30 日更新：添加了对修改文件的父目录的突出显示（就像 Atom 一样）。
2017 年 7 月 1 日更新：现在使用完整文件或目录路径完成文件匹配。 在此更改之前，如果目录与另一个更改的目录具有相同的名称，则会突出显示该目录。

你好，
我不知道此功能是否已实现？
我没有找到任何设置或扩展，因为它是近两年前打开的，我很困惑..

@sanjibukai该问题仍然存在，因此尚未实施。 不过，您可以使用@karabaja4在您上面的评论中创建的 hack。

我是新来的，但真的需要近两年才能添加这个明显的功能吗？
令人惊讶的是，直到最近我才听说过 vscode，但是当我听说它时，所提倡的主要功能正是 vscode 如何很好地集成 git。 确实很好。
可惜这个功能还是欠缺。。
尽管如此，保持良好的工作 vscode 团队👍

没有这个功能就无法保持专注。 每次我都必须记住我编辑了哪个文件。

+1

@karabaja4为什么不用你的 hack 做一个 PR 并获得关于如何正确实施它的反馈？

@saada如果我认为任何代码都可以集成到 VS Code 中，我会这样做。 运行后台git status进程肯定不是实现此功能的明智方法。 任何实现这一点的正确代码都必须从头开始编写，并在 VS Code 源代码框架内正确实现。 这是很多工作，不幸的是，目前我没有足够的时间可用。 对不起 ：（

当他们规定的指标已经被认为是原始帖子获得的 +1 数量而不是回复时，堆积不会有帮助。 此外，考虑到这是一个面向开发人员的工具，我有点惊讶于这里有多少权利并且不了解这里正在进行的开源流程。 功能请求在这里是一个未解决的问题。 您可以在帖子上对其进行 +1，也可以自己进行（大概与维护人员合作以确保它不会白费）并请求合并，或者只是保留它。 如果它对您来说是一项重要功能，那么请使用 Atom。 在我写这篇文章时，有超过 4000 个未解决的问题。 你必须要有耐心。

（或同时使用@karabaja4 hack - 感谢您的工作！）

+1
这样做是因为只听讨论devchat和更多评论的问题会得到更多关注

@karabaja4很棒的工作。 另一种方法：如何在初始化时运行git status ，然后在onFileSave事件被触发时更新？ 这会更有效率吗？

也许我们可以配置刷新git状态的方式。

+1 如果添加，这将非常有帮助

@Kaijun我不确定我将如何实现它。 onFileSave事件从何而来？

如果它来自文档保存时的代码（假设我知道如何附加到它），则在代码之外修改的文件将被忽略，移动和复制文件等更改也将被忽略。

如果它来自在解决方案树上实现的文件夹监视逻辑，则必须对整个树递归地执行此操作。 我不确定在性能方面是否值得。

@karabaja4我认为 Code 也会检测到外部变化。 因此，可能会使用去抖动系统连接到此类“事件”，以便同一时间间隔内的多个文件更改不会触发过多的 git 状态检查。 这可以工作！ 也许熟悉 fs 的人可以插话？

这真的不应该在积压中。 添加这个看似很小的功能具有非常实际的价值。 开发者的幸福伴随着一路走来。 令人沮丧的是，看到这个问题有数千个 +1，自 2015 年以来就被忽视了。

@kamok确实如此！ 虽然 Atom 很慢，但我确实有另一个选择......我回到了 WebStorm，它在与 Git 集成的方式以及你必须在 vscode 上安装扩展的其他功能方面不败，它仍然设法如此之快就速度而言，它看起来像是一个轻量级的编辑器，而不是一个 IDE。 仅此功能（文件资源管理器中的 Git 状态）仍然不足以留住 vscode 用户。 这只是杯水车薪。 这是我最不怀念的功能，来自 WebStorm。
我建议 vscode 团队看看 JetBrains 的人是如何做的。
对不起，但我已经尝试过......我已经与 vscode 斗争了几个月，等待更新一次又一次，但我仍然发现自己不断地关闭 vscode 并在 WebStorm 中重新打开项目：资源管理器中的 Git 状态树、藏匿处、用于本地更改的文件夹/树视图、分支比较、右键单击 > 与剪贴板比较……而这些就在我的脑海中。 如果他们真的想帮助开发人员，Vscode Git 集成还有很长的路要走。

_使用FastHub从我的三星 SM-G950F

@MrCroft如果您非常关心他们的工作方法，我建议您直接与团队联系，否则您会竖起大拇指 +1 并切换编辑器（如果它让您感到困扰）。

@cucumbur我已经做了（从 vscode 切换过来的）。 我只是在表达我的悲伤，因为我真的很喜欢 vscode 的感觉。 我会喜欢它有良好的 Git 集成，这样我就可以继续使用它。 相信很多人都有同感。
我还是会关注的。 也许，谁知道呢，在“不太遥远的未来”它会完成......除了 vscode，我实际上是一个巨大的微软粉丝......软件和硬件，他们构建了非常高质量的东西 10 次中有 9 次. 我只希望 vscode 能成为 9 个。

_使用FastHub从我的三星 SM-G950F

@kamok每个新问题都会进入待办事项并一直保留到他们被解决为止。 我认为这个功能根本没有被忽视。 它只是需要比你意识到的更多的改变。 据我所知，他们想让它成为扩展 api 的一部分，目前文件树缺乏很多功能来实现这一点。

如果您按竖起大拇指对问题进行排序，您会看到这个问题是第二受欢迎的问题，第一个正在处理中，几乎完成。 我很确定他们会在另一个完成后立即开始工作。

不过，对这个线程的偶尔更新会很棒。

从 atom 切换但在没有突出显示更新文件的大型项目中使其难以使用。
切换回 Atom 直到此功能可用

也许值得一提的是，对我有用的替代/临时解决方案是在“打开编辑器”视图中复制树结构。 通常，视图向我显示“更新”的文件，但它只是文件名的转储，因此更难使用，而不是是否清楚在项目中找到这些文件的位置。

有任何更新吗？

https://www.youtube.com/watch?v=rTyN-vvFIkE&t=4s

我受虐狂👎我自己的评论。

我一直在尝试 VSCode，但由于缺少此功能，因此无法切换。 直到我尝试切换时才意识到我对 Atom 中的此功能有多么依赖。

只等这个从atom切换到VS代码，希望它尽快实现。

+1

两年过去了。。。

令人惊讶的是，您的评论并没有最终改变这一点。 我们这些关心发展和潜在贡献的人订阅了这些问题线程，您的评论没有任何帮助，它向 99 人发送了一封无用的电子邮件

嘿，除非你尝试，否则你不会得到任何结果，对吧？

一开始我很想念它，虽然拥有它会很方便，但“差异资源管理器”（垂直菜单中的第三个图标）非常强大，非常有用

+1
如果这个实现 wooow 会很棒......！

我写了一个 gulp 任务来简化hack的安装（仅限 VS Code 1.15）。

git clone https://github.com/karabaja4/vscode-explorer-git-status.git
cd vscode-explorer-git-status
npm install
gulp install # as root/administrator

PS 尚未在所有平台上进行测试，如果有人能在 OSX 上试用，将不胜感激。

@karabaja4似乎你的“黑客”在 vscode 本身中实现起来并不复杂。 由于似乎 vscode 开发人员不会很快解决这个问题，也许您可​​以创建一个拉取请求？

@karabaja4谢谢你！ 在 macOS Sierra 上为我工作，VSCode 1.15.1。

@karabaja4谢谢！ 在 Fedora 26，VSCode 1.15.0 上工作。 仅此一项就使从 Atom 的切换变得更加方便。

@karabaja4 +1 谢谢！！ 在 Ubuntu 14.04 64、VSCode 1.15.1 上为我工作（手动安装）

+1

@karabaja4 +1 这太棒了。

+1

@马蒂加一

_使用FastHub从我的 HTC MSM8996 发送给

@ibrokemypie减二

使用 Lolbug 从我的 HTC MKB826262 for arm32 发送

有关于此功能的消息吗？

+1

+1

+1

@karabaja4谢谢男人 =D <3

+1

哇，这应该是两年前实施的

@eosrei +1

+1

+1
让我们面对现实； 我喜欢 VSCode，但 Git 选项卡真的很烂

@karabaja4嗨，1.16 刚刚发布，你会在这个版本上移植你的 hack 吗？ 谢谢。

编辑：适用于 1.16，但不适用于使用多根工作区。

@ karabaja4👍

@karabaja4刚刚

+1

+1

+1评论应该是对 GitHub 问题的自动禁止...

如果 GitHub 只是解析 +1 个帖子并自动将它们替换为对原始帖子的竖起大拇指的表情符号反应会更好。

@karabaja4你的 hack 在 OSX 10.12.6 上运行 - 太棒了！ 谢谢你。

git clone https://github.com/karabaja4/vscode-explorer-git-status.git
cd vscode-explorer-git-status
npm install
gulp install # as root/administrator

唯一的问题是我现在在启动时收到警告消息。 幸运的是，这只是一个警告。

VSCode 版本 1.16.0

+1

是否有尚未实施的原因，或者是否有添加此功能的时间表？

昨天，我回到 Atom 一个小时以使用他们最新的 ide 更新，我认为我的生活在文件树视图中使用彩色文件非常简单。

编辑：刚刚找到了一个解决方法。 在其中一个 vs 代码文件中添加一行（< 1 分钟的努力）就像一个魅力！ https://github.com/karabaja4/vscode-explorer-git-status

@timc13 @fro3clr @WLLR9505 @ngortheone @edokeh @ncnegoleo @loehx @aecorredor @BenGale

你有没有看到你可以使用表情符号反应而不是发布+1 ？

每次我们在 github 上发表评论时，该主题的所有订阅者都会收到通知，一些用户也会收到电子邮件。 阅读一封写成的电子邮件有点沮丧： +1 ，您可以在这些评论中看到，有很多 :-1:。

如果我们都开始使用这些反应，社区会很感激：
https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments

对于此信息的任何冒犯以及收到此通知的其他人，我深表歉意。

我在其他线程中读到过，微软根据 +1 评论的数量对功能的优先级进行了评级。 如果我犯了这个错误，我深表歉意，并且在任何方面都不是一个功能的排名。 我删除了我的评论。 无论哪种方式，兄弟的侵略性态度是什么？ 你可以用更好的语气指出同样的事情@leocaseiro

干杯。

嗨@aecorredor ，如果听起来很粗鲁，我深表歉意。
我的母语不是英语，也许我翻译的其中一个表达听起来很糟糕。 请帮助我改进该评论的描述。 我应该替换烦人这个词吗？ 无用？ 谢谢。

PS：我很高兴你编辑了我在我的电子邮件中阅读的世界，因为我可能听起来很粗鲁，但我从来没有打算冒犯任何人。

更新：我已经替换了我之前的评论，如果听起来更好，请告诉我。 谢谢

嘿@leocaseiro ，

对不起，首先写了那个坏词。 我其实意识到
语言障碍可能是造成混乱的原因。 但
是的，我会用以下内容替换这两个词：
“拜托，我们都在努力改善 github 的整体体验
开放问题/功能请求，如果人们开始使用就好了
表情符号反应而不是像“+1”这样的评论，这只是创造
线程中不必要的开销，并触发并非真正的电子邮件
以任何有意义的方式做出贡献。 请参阅此链接以了解如何
表情符号反应有效：{在这里链接}

干杯，并没有什么难受的感觉。

最好的。

2017 年 9 月 18 日星期一晚上 11:44，Leo Caseiro通知@github.com
写道：

嗨@aecorredor https://github.com/aecorredor ，如果听起来我很抱歉
粗鲁的。
我不是母语为英语的人，也许我的翻译之一
表情听起来很糟糕。 请帮我改进描述
那个评论。 我应该替换烦人这个词吗？ 无用？ 谢谢。

PS：我很高兴你编辑了我在我的电子邮件中阅读的世界，因为我可能
听起来很粗鲁，但我从来没有打算冒犯任何人。

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/Microsoft/vscode/issues/178#issuecomment-330420547 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AIsVa9fgWXPMFBgkZdHjQHKhUEDJb8Bmks5sjziWgaJpZM4GlYyH
.

https://github.com/Microsoft/vscode/blob/master/CONTRIBUTING.md

使用反应代替“+1”评论。

+1

我真的希望在之前的评论之后 +1 的数量会减少，但突然又出现了另一个 +1 😁。

很遗憾，因为程序员经常责怪用户没有阅读错误信息，但无法阅读一些评论或说明。

也许值得在 README.md 上放一些东西来要求用户使用反应而不是评论 +1？ 也许在 CONTRIBUTING.md 上它有点隐藏。

我不知道，我想我会退订并等待发行说明准备就绪。

我创建了一个 Gist 来处理这个问题。 @karabaja4的修复没有正确地使被忽略的文件/文件夹变灰（请参阅他的问题）。 @dseipp的 PR 从未合并过。 他的公关仍然有问题（我认为缺少阶段性支持？），所以我修复了它。

因此，如果您想让它更好地工作，请查看我的要点： https :

@ikatyang ：抱歉，这是否意味着此功能将于 10 月（2017 年）推出...？

@nkkollaw链接来自此评论： https :

评论只是要求在这里讨论与此问题相关的事情，而不是在“迭代计划”中（并要求用英语讨论它们）。

啊，明白了@tiangolo ，谢谢。

我会尽量忍受 Atom，直到有一个 API 来实现这个功能（抱歉，我根本没有能力帮助解决这个问题）。

我正在努力在项目本身内进行更新。
现在，我做了一个有效的概念证明，但我没有通过 tslint，因为我仍然需要了解层才能将所有内容放在正确的位置。
我会在这里发布一些更新，如果有人想帮助我，我会稍后将链接放到我的拉取请求中，因此欢迎您提供帮助。

计划于 2017 年 10 月迭代！！ 👍

我们确实有第一个版本。 大家放心，这将在十月份到来。

多一点信息：

• 颜色将在主题中定义，这意味着它们可以根据您的口味量身定制
• 会有一个设置来启用/禁用这个
• 这不是版本控制所独有的。 我们也在研究在文件资源管理器中突出显示错误/警告（参见 #782），我们正在考虑将其公开给扩展作者。

开放问题：

• 只使用一种颜色就足够了吗？ 是否还应该有文字和/或图标提示？
• 父母应该选择哪种孩子状态？ 这应该按重要性排序吗？ 这很容易出现错误和警告，但更重要的是，已更改、未跟踪或忽略的文件？
• 我们是否也应该在“打开编辑器”存储桶和/或文件选择器等中显示这些文件装饰？

当事情发生时，我会及时更新这个问题。 与往常一样，使用情绪而不是“+1”-评论。 谢谢和快乐编码！

就我个人而言，我在上图中看到的就足够了。 看起来很棒，谢谢！

它似乎错过了.gitignore忽略的深灰色文件？

您不会为内部被忽略的文件更改父文件夹的颜色（变灰）。 如果文件夹本身被忽略，您只能将其灰显。 请查看我的评论/修复一些评论。 它使 Git 转储状态并检测它是目录还是文件。 简单地向文件树中的文件/文件夹添加类就可以了……例如“git-status-modified”或“git-status- added”。 然后主题可以发挥它们的魔力。

如果你们能让我们拉取你们所做的工作，那么我们就可以玩它，并创建 PR，那就太好了。 老实说，如果它搞砸了，如果无法在合理的时间内实现可行的解决方案，人们可​​能会停止使用 Code。 许多人（包括我自己）因为类似的问题离开了 Atom。

我也认为如果有错误，也许在树中的文件名之前或之后使用一个点。 这将是不引人注目的，让主题为它们设置样式，并且不会干扰 Git 颜色突出显示。

是的，这必须向扩展开发人员开放！ 早就该做了。 为什么我们不想控制文件树来制作很酷的扩展或修复你们没有的东西？

它似乎错过了深灰色 .gitignore 忽略的文件？

当然，它正在进行中，事情一次发生。 被忽略的文件也会在 10 月份出现。

如果你们能让我们拉取你们所做的工作，那么我们就可以玩它，并创建 PR，那就太好了。

当然，这一切都在joh/feco分支中。 有一种新的装饰服务，它使用提供者提供实际数据。 在消费端是我们用来渲染文件名的文件标签

您不会为内部被忽略的文件更改父文件夹的颜色（变灰）。 如果文件夹本身被忽略，您只能将其灰显。 请查看我的评论/修复一些评论。

我认为“被忽略的文件和他们的孩子（如果有）是灰色的”是很清楚的。

@nkkollaw你在说什么？！

在@jrieken 中说：

“Which child status should a parent pick up? Should this go by importance? That's easy with errors and warnings buts what's more important, a changed, an untracked, or an ignored file?“

他指出一个被忽略的文件可能会影响父文件夹的状态，这不应该！

你的被动攻击性信息只是用无益的信息阻塞了这个线程......

@WadeShuler ：我不知道你在说什么。

我刚刚指出，忽略文件及其子项应该显示为灰色，很明显，此定义不要求忽略文件的父项显示为灰色。

至于：

你的被动攻击性信息只是用无益的信息阻塞了这个线程......

我不知道我的信息是如何被动攻击的——我猜你不知道它是什么意思——但你是阻塞这个线程的人，因为你是唯一一个在我的消息后发表评论的人。

奇怪的。

哇..好主意！ 我喜欢！

我希望在右列中使用 xcode 之类的单字符文本提示。 使文件易于在视觉上过滤/跟踪。

@nkkollaw我说：

您不会为内部被忽略的文件更改父文件夹的颜色（变灰）。 如果文件夹本身被忽略，您只能将其灰显。

显然，我说的是父文件夹，而不是子文件夹。 在这里，我给你画了一张图：

这里是父目录中的.gitignore ， web供参考：

/index.php
/index-test.php
!/assets/css
!/assets/fonts
!/assets/js
!/assets/themes
/assets/*

我的消息是对@jrieken对 WIP 的回复的回应，他在这里说：

父母应该选择哪种孩子状态？ 这应该按重要性排序吗？ 这很容易出现错误和警告，但更重要的是，已更改、未跟踪或忽略的文件？

表示“被忽略”的文件/文件夹的父级可以具有状态，但它没有。 因此我的答复。 您混淆了您视觉上看到的内容，以及 Git 实际用于忽略列表的内容

➜  yii2-mlm git:(master) ✗ git status --short --ignored
 M backend/views/layouts/_left.php                   <-- Modified File
?? backend/controllers/PayoutController.php         <-- Added File
?? backend/views/payout/                            <-- Added Directory
?? common/models/Payout.php                         <-- Added File

!! backend/runtime/logs/                            <-- Ignored Directory (everything inside)
!! backend/web/assets/6f57f06b/                     <-- *special rule - Ignored Directory (everything inside)
!! backend/web/assets/9e65c758/                     <-- *special rule - Ignored Directory (everything inside)
!! backend/web/assets/1ecaa825/                     <-- *special rule - Ignored Directory (everything inside)

!! node_modules/                                    <-- Ignored Directory (everything inside)
!! vendor/                                          <-- Ignored Directory (everything inside)

*special rule意味着它是在.gitignore中用特殊规则定义的，因此它不只是backend/web/assets/而是随机命名的资产目录。 在处理其内容被忽略的目录时，您不必指定每个被忽略的文件。 例如vendor或node_modules目录。 他们在git status忽略的条目中只有一个条目。

在文件树，你需要一类添加git-status-ignored到以开头的所有元素（文件和文件夹） backend/web/assets/6f57f06b/ 。

匹配文件树文件夹backend/web/assets/6f57f06b/的 CSS 是这样的（目前需要 2 条规则！）：

#workbench\.view\.explorer .explorer-folders-view .monaco-tree .monaco-tree-rows .monaco-tree-row .explorer-item[title="/Applications/XAMPP/xamppfiles/htdocs/yii2-mbn/backend/web/assets/6f57f06b" i] {
    opacity: 0.4 !important;
}

和

#workbench\.view\.explorer .explorer-folders-view .monaco-tree .monaco-tree-rows .monaco-tree-row .explorer-item[title^="/Applications/XAMPP/xamppfiles/htdocs/yii2-mbn/backend/web/assets/6f57f06b/" i] {
    opacity: 0.4 !important;
}

注意：在第一条规则中，我们只匹配带有=符号的标题，非常准确！ 在第二条规则中，我们将所有标题与^=匹配，因此是字符串的开头，匹配所有比这更深的内容（所有孩子）。

匹配一个目录需要 2 个 CSS 规则。 因此，我认为在执行此操作时，我们应该继续在 HTML 元素上为目录添加title以包含尾部斜杠。 您可以在此屏幕截图中看到我在说什么：

是的，您的评论是被动攻击性的，因为您没有真正说出这些话就粗鲁/狡猾/蹩脚。 另外你错了。 没有人说任何关于孩子的事情，这甚至不是我们在谈论的。

@jrieken
我的 Atom 设置的工作方式：“已编辑”优先于“已添加”。 删除文件不显示任何状态。 “staged”没有状态。 我认为其他人应该检查他们的 Atom 设置，看看这是否也适用于他们，这不仅仅是我的设置。 最好为每种情况添加代码，并让用户编辑它以按照他们想要的方式工作。

也许添加多个类，所以父目录一直在树上，会有“git-status- added”和“git status-modified”。 如果某些内容已在其下删除，甚至可能会加入“git-status-deleted”。

然后只需使用 css 来匹配它们。 如果您想要.git-status-added.git-status-modified的不同颜色，您可以使用带有绿色下划线的橙色字体（橙色表示修改，绿色表示添加）。 如果它只有.git-status-added类，则将字体设为绿色。

一旦你向它们添加类就没有关系了，每个人都可以随心所欲地制作一些 CSS。 不过，您会想要一个“相当不错”的默认设置。

当我有时间时，我会拉那个分支，然后检查一下。

如何处理 lint 错误和 git 状态？

Atom 在文件名下放置了一条红色波浪线，如下所示：

我认为我们应该在与 git status 相同的元素中添加一个诸如lint-error的类，我们（和主题）可以通过我们自己的样式表覆盖它。

所以文件树中相同元素的 div 就像我上面的例子一样（后端/网络/资产/6f57f06b）：

<div class="monaco-icon-label folder-icon 6f57f06b-name-folder-icon explorer-item" title="/Applications/XAMPP/xamppfiles/htdocs/yii2-mbn/backend/web/assets/6f57f06b" style="display: block;"> </div>

看起来像这样，当我们同时应用git-status-edited和lint-error的 git status 时：

<div class="monaco-icon-label folder-icon 6f57f06b-name-folder-icon explorer-item git-status-edited lint-error" title="/Applications/XAMPP/xamppfiles/htdocs/yii2-mbn/backend/web/assets/6f57f06b" style="display: block;"> </div>

然后我们可以通过 CSS 进行匹配：

.folder-icon.explorer-item.git-status-edited {
    color: #cbcb41;  // yellow
}

// Adds a squiggly red line under the filename in the left tree-view list
.folder-icon.explorer-item.lint-error a.label-name {
    background-image: linear-gradient(45deg, transparent 65%, #cc3e44 80%, transparent 90%), linear-gradient(135deg, transparent 5%, #cc3e44 15%, transparent 25%), linear-gradient(135deg, transparent 45%, #cc3e44 55%, transparent 65%), linear-gradient(45deg, 
    transparent 25%, #cc3e44 35%, transparent 50%);
    background-size: 8px 2px;
    background-repeat: repeat-x;
    background-position: left bottom;
}

你们有 Slack 吗？ 提交中有很多编辑过的文件。 我正在寻找您将 git status 颜色应用于文件树的确切位置。 它在/extensions/git/src/repository.ts 中吗？

感谢大家并感谢您澄清更改、未跟踪和忽略文件的规则。 明天内部人员将提供此的早期版本。

几件事

• 默认情况下，有 color 和 bagde 的组合。
  
  
  
  • 启用/禁用图标： "explorer.decorations.badges": true|false
  
  
  • 使用"explorer.decorations.colors": true|false启用/禁用颜色
  
  
• 颜色显示在文件树、打开的编辑器部分和 SCM 视图中
• 一开始有三种颜色。 您可以在workbench.colorCustomizations设置中自定义它们。 颜色是gitDecoration.modifiedResourceForeground ，
  gitDecoration.deletedResourceForeground ,
  gitDecoration.untrackedResourceForeground ,
  gitDecoration.ignoredResourceForeground ，和
  gitDecoration.conflictingResourceForeground
• 请注意，设置等的名称可能会更改，可能会添加新设置，可能会再次删除其他设置。

仅供参考 - 编辑以反映初始帖子后所做的更改

我认为最好不要将右侧图标应用于父目录。 至少可以有一个选择。

这似乎已在内部版本中更新， scm.fileDecorations.useIcons和scm.fileDecorations.useColors被替换为scm.fileDecorations.enabled ，它提供了图标和颜色。

我只想有颜色而不是图标。 IE scm.fileDecorations.useIcons : false和scm.fileDecorations.useColors : true的“旧”行为

我曾尝试使用explorer.decorations.badges和explorer.decorations.colors但它们似乎没有效果。

编辑：
我正在运行 1.18 版内部人员，在 Windows 10 上提交 f1ee80be081b0d...
（如果关于对话框中的文本是可高亮的，以便您可以复制，那就太好了）

感谢您将这些放在一起@jrieken ！

有几个想法：

• 看起来所选颜色仍然是旧灰色而不是状态颜色
• 同意是否有图标的选项（根据@FredrikFolkesson ）
• 使用图标显示，如果修改/更新的颜色是浅色，则“M”或“U”应该是深色的（反之亦然），这样对比度就存在并且更容易阅读。

期待不必在每次构建时更新 main.js 文件来获取颜色！！！

小问题（我使用截至 10 月 16 日的最新内部人员）报告， @jrieken ：如果当前选择了此文件，则不会显示项目树中修改后的文件名的颜色。 这里的期望是无论项目树中的文件是否被选中，颜色都应该相同（表示修改后的文件）。

我想解决的另一个问题是相同的颜色编码不仅适用于项目树，而且适用于打开的编辑器部分。 目前，无法在打开的编辑器部分查看哪些文件被修改，哪些没有。 能够快速找出哪些编辑器用于修改文件非常方便，因此可以在他/她修改的文件之间快速跳转，而无需尝试记住当前修改文件的名称。

这将是一个很棒的功能。 来自 Atom 的 VSC 新手，我非常想念它。

也刚从 Atom 移过来，也缺少此功能。 计划何时发布具有此功能的版本？

同样，这也很重要，因为 gitignored 文件在列表中太突出了，它会与所有内容混在一起......

嗨，我想我们还需要一个颜色键来更改徽章前景色 (#36246)

感谢大家的持续反馈。 我已经更新了我的初始摘要评论以反映最近的变化。 我还确保无需重新加载即可反映对设置的更改，并且状态颜色优于选择颜色。

默认情况下，我们仍然使用颜色和徽章，主要有两个原因：不是每个人都立即知道颜色的含义，并且拥有徽章（及其工具提示）可能会使这一点不言自明。 其次，有些人，实际上就像我一样，很难区分这些颜色，而徽章的目的是让这更容易理解。

@jrieken你能告诉我 CSS 类是否被应用于左侧文件树资源管理器上的元素吗？ 这将提供最佳的可扩展性，并使主题开发人员和我们个人可以轻松自定义和覆盖颜色。

例如：当您的新代码修复将文件或文件夹标记为已添加时，它应该添加一个类，例如git-status-added 。 然后我们可以定位是否通过我们的样式表来自定义颜色，而不会被您提供的开箱即用的东西所困扰。

@WadeShuler我们的主题/颜色自定义不能直接使用 css，而是使用我们称为主题颜色的东西。 这是一种间接方式，为某些事物命名，例如editorLineNumber.foreground是行号的前景色的名称。 主题为这些名称分配颜色，编辑器在渲染时选取这些值。 查看更多背景信息： https :

对于下一个内部人员，可能在明天 19 日，将有针对被忽略文件（ git.color.ignored ）的特殊渲染，并且颜色/徽章将显示在“打开编辑器”部分中。 我已经相应地更新了https://github.com/Microsoft/vscode/issues/178#issuecomment -335511695。

@jrieken 太棒了！ git 徽章前景的颜色键怎么样？
https://github.com/Microsoft/vscode/issues/178#issuecomment -336904514

非常好的作品！ 很高兴看到这个功能出现在 vscode 中。

在当前实现中，子模块中的修改文件尚未正确标记为正在修改。

在以下示例中：

主存储库在src/components/包含一个子模块。 在子模块中修改了几个文件。 vscode 正确报告src/components/已修改，但并未指示子模块中进行了哪些更改。

Atom 确实可以正确识别修改后的文件：

此问题可能与https://github.com/Microsoft/vscode/issues/7829有关

@jrieken 太棒了！ git 徽章前景的颜色键怎么样？

@equinusocio不用担心，它会发生，但需要一些思考。 定于10月

@jrieken谢谢！ 我错过了一些东西......文件夹图标也得到了修改/添加的颜色？ 在编辑/修改 git 时，是否有新的键添加到图标主题以设置文件夹的不同图标？

@jrieken - 1.18 中的问题。 我想说谢谢你到目前为止所做的工作。 我刚刚测试了 v1.18 Insiders。 我浏览了上面的线程，所以请原谅如果你已经在 1.19 的作品中解决我在下面提到的问题。

1) 文件树中的“已添加”状态看起来像带有“U”标记的“已更新和未合并”。 添加的文件应该有一个“A”标志。

2) git.color.added没有颜色选项

3) git.color.ignored没有颜色选项。

4）（故障）它将“添加”文件视为“未跟踪”。 我检查了一个“添加”的文件，它看起来像在 html 中，它认为它没有被跟踪。 （ span标题表示“未跟踪”，类是monaco-decorations-style-32 ，“U”图标）。 当为git.color.untracked更改workbench.colorCustomizations上的颜色时，这一点很明显，因为它控制应该是“添加”的文件。

5) 支持“R”状态，对于“重命名”或移动，添加“R”徽章，并添加匹配的git.color.renamed设置。

谢谢，我期待着尝试 1.19 👍

@danjjl #7829 有一个悬而未决的 PR 应用后，git 子模块确实获得了着色。

有一个潜在的问题，如果子模块被更改，我不知道它（子模块的根目录）是否会被视为主 git 存储库中目录状态的颜色，或者不同的基于包含的文件的颜色。

也就是说，我不知道子模块目录的颜色是基于父目录中的'git status'，还是子模块中的。 反正也可能没有关系。

@jrieken您是否有 Slack 小组或其他地方可以讨论此问题？ 我可以提供帮助 :) 我能够从主分支拉取、开发和调试当前的更改。 我修复了显示为“U”的“添加”文件，甚至添加了“分阶段”支持。 由于这是我第一次参与该项目，我正在将其重置为 master 并重新进行。 我做了很多改变，想像外科医生而不是核武器一样进入。

为什么先检查raw.x + raw.y然后检查raw.x然后raw.y ？ 这似乎导致它匹配 2 个不同的状态。

为什么ADDED / INDEX_ADDED 、 MODIFIED / INDEX_MODIFIED和其他一些状态常量有 2 个？ 我了解所有不同的 git 状态，但为最终用户处理它是有意义的，而不是 Git 状态的命名。 ADDED应该用于您现在拥有的UNTRACKED以便设置代码为git.color.added 。 我认为其中一些状态常量是重复的，应该简化和清理。

_M <-- underscore = space/nothing 的 git status 将匹配raw.y并且你们将它作为INDEX_MODIFIED 。 这是不正确的， x = nothing 和 y = M代表staged 。

出于某种原因，有时是随机的，它似乎没有反映变化。 此外，似乎 git status 更改是从上到下递归扫描的。 如果您有一个大型项目，您可以通过文件夹/文件查看“已忽略”状态。 为了加快速度，更深入地导航，似乎将其插入该目录并将它们变灰。 -- 这个过程会大大减慢系统/VSCode 的速度吗？ 有没有人对其进行基准测试？ 当父级被忽略时，确实不需要遍历每个文件/文件夹。 孩子们应该从他们的父母那里得到他们的状态。 -- 如果您有 5,000 个文件ignored但都在 2 个目录中（即：node_modules、vendor），那么我们不应该处理 5,000 个文件，只处理 2 个控制其子项外观的目录。

我将在今天晚些时候重做我的更改并发布 PR。

再次感谢您的工作。 我只是想帮助你而不是对你喋喋不休，因为我真的可以做到，哈哈👍

@WadeShuler我可以回答其中的一些问题。 我假设您正在repository.ts 中查找Repository.updateModelState()。 如果你注意到 raw.x + raw.y 检查，它们都会返回，所以你实际上不能做 raw.x 和 raw.y。 raw.x 和 raw.y 分开的原因，以及 INDEX_* 的原因是每个 INDEX_* 都是上演的，只是上演的东西会发生变化。 如果你用 STAGE 替换 INDEX，我认为它更有意义，尽管他们使用的逻辑在技术上是正确的。 请参阅https://git-scm.com/docs/git-status ，尤其是“XY 含义”表
（编辑：哇，格式很糟糕。只要去原来的。这是一个红色的表格，大约在一半的地方。）
这显然是他们用于整个事情的内容。

而且我认为您在 _M 情况下错了，这将匹配 MODIFIED，未修改的索引（即未上演）。 当然，除非您正在其他地方查看此代码的副本。

@petkahl谢谢，我熟悉Git 状态短格式。 几周前我用它来修复我的

有可能（以某种方式）获得_M （下划线 = 空格）。 我不确定如何、为什么、何时……我今天早些时候得到了这个（以及几周前在我的 Gist 上工作时）：

➜  git-test git:(master) ✗ git status -s --ignored                                  
 M added.php       <-- notice space before M
A  test2.php
?? untracked.php
!! vendor/

现在几个小时后，我运行它并得到“A”。 我不知道从那以后发生了什么变化..

➜  git-test git:(master) ✗ git status -s --ignored         
A  added.php
A  test2.php
?? untracked.php
!! vendor/

当我为我的 Gist 做研究时，我想我得出的结论是有可能获得“A_”和“_M”作为staged。 我还发现了一个比 git-status 文档更清楚地分解状态的站点，我只是找不到它了，哈哈。

您还可以为暂存和修改的文件获取“AM”。 创建一个新的空文件，添加（暂存），编辑文件并保存，检查状态：

➜  git-test git:(master) ✗ touch test.php         <--- create file
➜  git-test git:(master) ✗ git add test.php       <--- add/stage
➜  git-test git:(master) ✗ nano test.php          <--- edit, add some text, save
➜  git-test git:(master) ✗ git status -s --ignored
A  added.php
AM test.php              <--- modified after staging
A  test2.php
?? untracked.php
!! vendor/

那么这应该有 2 个徽章，“[S][M]”吗？ 我宁愿知道我上演了哪些文件。 采摘樱桃时很有用。 仍然查看您是否修改了暂存文件可能很有用。 它至少应该有一个舞台徽章。

@WadeShuler通过提交和修改，我可以始终如一地获得 _M。 这意味着它在索引中没有改变（_=space），但在工作树中被修改。
所以：
创建文件：??
git 添加文件 A_
git commit（不在状态，但相当于空间空间）
修改文件：_M
git 添加文件 M_
再修改一下：MM

当它有两个徽章时，我真的没有意见。 我从来没有在不查看状态窗口的情况下检查，它清楚地分解了它，就像常规的 git status 一样。 也许只是一个让你选择哪个优先的设置？ 我可以看到两者的论据。 或者两个徽章，我猜。 着色会一样吗？

我添加了Staged支持。 您可以在此处查看更改： WadeShuler/ vscode:gitstatus-fix 。 我还让 Git 状态选项卡上的一些徽章看起来更好一些，让它们更大一些。

出于某种原因，它删除了vendor目录的变暗/忽略，但它里面的内容仍然是灰色的并被忽略。 我不明白为什么我的简单修改不再使vendor目录变灰？ 这是我刚刚所做的唯一问题，以及为什么我还没有发布 PR...

如果要包含暂存文件颜色/图标，这绝对是可选的。 就个人而言，我不想在我的列表中看到与原始新/修改颜色不同的颜色。

一旦你开始包含 staged，它会很快变得复杂，因为有可能包含 new/new-staged/modified/modified-staged/modified-staged-modified/new-staged-modified 等的所有组合和排列。 ，这将导致巨大的颜色矩阵和混乱。

我投票我们不要把事情复杂化。

我同意@dseipp。 这就是我在最初的 hack 中没有合并对暂存文件的支持的确切原因，因为我认为暂存文件没有用颜色。

颜色突出显示的目的是让我可以在文件资源管理器中一目了然地找到新的/修改过的文件。 如果我暂存一些文件，通常是在提交之前或者我已经完成了它们，所以我没有任何用它们正常着色。

如果我们为每种可能的 git status 类型添加颜色，文件浏览器将开始看起来像一棵圣诞树，并且很难看到实际发生的事情。

@jrieken 还有一个错误报告，发生在最新的内部人员

• VSCode 版本：Code - Insiders 1.18.0-insider (82dcf9835265cd0a45ec135587ae2a82673f1c8f, 2017-10-20T04:24:25.632Z)
• 操作系统版本：Windows_NT x64 10.0.15063

基本上，VS Code 会不时“忘记”某些文件被修改并需要相应地着色。 例如，我目前修改了 6 个文件。 VS Code（正确）在 git 按钮上显示数字“6”。 但是，在项目文件树中，我只看到一个黄色文件，其他五个文件看起来没有被修改。 有趣的是，所有 6 个文件都在打开的编辑器部分正确着色。

@dseipp它可以是可选的。 但是，在您暂存文件之前，您永远不会看到“暂存”颜色......所以它甚至在 99% 的情况下都不会被看到，并且不应该真正打扰任何人......

@karabaja4我不同意它没有用。 你提出了一点，你从不使用/注意/需要分阶段着色......

颜色突出显示的目的是让我可以在文件资源管理器中一目了然地找到新的/修改过的文件。 如果我暂存一些文件，通常是在提交之前或者我已经完成了它们，所以我没有任何用它们正常着色。

因此，即使添加了此功能，也不应该打扰您......

能够查看暂存文件有助于挑选您将要提交的内容。 如果我们更改了 100 个文件，那么需要将它们分组，我们可以浏览文件树并轻松查看暂存的内容，并捕获我们错过的文件，以确保它们在同一个提交中。

你有多少次提交了一些文件，然后意识到你错过了一个？ 然后，您有 2 个选项，修改上次提交以包含丢失的文件，或进行新提交。 与团队合作时，让他们在同一个提交中更清晰、更容易混淆。

在暂存点，文件是否已添加、修改或其他任何内容都无关紧要。

老实说，Visual Studio Code 处理 Git 的方式很笨拙且有缺陷。 大文件树，您可以从字面上观察通过文件/文件夹的颜色滴落。 它会随机掉色...

我认为整个 Git 支持需要从头开始重写。

我还想表达我对暂存文件着色的支持（只要我能启用它，就可以了）。

这是我的工作流程：我开始处理一些功能/错误修复，使其处于“OKish”状态，这意味着代码或多或少可以工作，但需要一些润色/调整/清理或重构。 在那一刻，我上演了我的改变。 然后执行清理和重构。 如果重构失败或变得过于混乱，我只会恢复到暂存状态。

能够查看我当前正在修改哪些文件是非常有益的，当我暂存更改时，我不想丢失所有这些信息并进入没有颜色的普通树。

@vvs我同意暂存文件不会丢失颜色。 颜色应该保持到提交。 我只是希望分阶段颜色保持新/修改的颜色，而其他分阶段颜色保持可选。

也许 Staged 可以保持相同的颜色，但只需添加某种高光或粗体以使其形成对比。

查看现有技术可能会有所帮助.. 不记得看过分阶段指标，但也许时代已经改变

文件资源管理器中用于修改/取消暂存/...文件的图标真的有必要吗？ 我的注意力有问题，所以颜色和图标很容易分散我的注意力。 它不能是可选的并默认禁用吗？ 我是唯一一个被他们分心的人吗？

从用户体验的角度来看，有时少即是多，许多人不会费心寻找禁用这些东西的选项，而是会继续受苦甚至更换编辑器。 我认为仔细考虑这一点并决定这是否真的需要更好的用户体验是一件好事（我认为这是这些图标的重点。）

*我没有时间阅读关于这个问题的每一条评论，所以请告诉我我要问的问题是否已经讨论过，我会花时间尽快阅读所有内容，以便与我保持一致说了些什么。 谢谢。

我认为仔细考虑这一点并决定这是否真的需要更好的用户体验是一件好事（我认为这是这些图标的重点。）

https://github.com/Microsoft/vscode/issues/178#issuecomment -336960308 是我们默认有颜色和徽章的原因。 同意它使用户界面更加混乱，为可访问/包容但又光滑和干净的建议开放。

@jrieken谢谢！ 你能指出我引入徽章的提交吗？ 我将尝试找到对这两个问题都有益的东西（难以看到颜色或不知道它的用途，以及分心问题）。

@jrieken让我们从 Xcode 中获取一个页面并使徽章更微妙。

徽章对于提示新手很有用，但在学习颜色后它会变得混乱。

对于额外的自行车棚，我更喜欢用git.color.ignored （上面的_left_）着色的徽章，因为它们具有相同的视觉重要性。 也就是说，淡出但不要消失，以防我需要你。

如果我们确实实施了微妙的徽章，则应更新源代码管理侧边栏徽章以保持一致性。

无论徽章讨论的方向是什么，徽章设计至少可以与 Git 侧边栏中的设计保持一致吗？ 为 Explorer 侧边栏设计一种而为 Git 侧边栏设计不同的设计感觉有点脱节。

我喜欢@jayjun 的单字母建议。 我今天试试看。

如果我们确实实施了微妙的徽章，则应更新源代码管理侧边栏徽章以保持一致性。

那会发生的，这是我十月份的计划。

我已经用最新的屏幕截图和颜色名称更新了https://github.com/Microsoft/vscode/issues/178#issuecomment -335511695。 此外，对于明日的内幕，我们将在 SCM 视图中显示相同的徽章，但没有彩色标签。 像这样

它看起来更好@jrieken - 感谢您的不断努力。 我觉得徽章好看多了！

徽章应该是U吗？ 我认为社区应该参与进来。 U让我首先想到updated 。 我知道它是 Git 术语中的untracked ，但我认为A更合适，特别是对于那些不熟悉底层术语的人来说， U是未跟踪的。 - 我个人投票支持A的添加。 就像，它已添加到您的存储库中。

然后支持staged （通过设置可选），它非常接近👍

@WadeShuler ，未跟踪的问号（？）怎么样？ 我不喜欢 A，因为它对 git 的含义与此处的含义不同，至少在我看来是这样。

编辑：但我同意你可能会感到困惑。

我想我可以带问号。 但是，我不认为代码
只支持 Git，是吗？ 我认为我们不应该在视觉上看待它
编辑器为“Git”，但总体上有更多的版本控制。

无论如何，我真的不喜欢“U”lol

2017 年 10 月 24 日星期二下午 2:20 Peter Kahle通知@ github.com
写道：

@WadeShuler https://github.com/wadeshuler ，问号怎么样
(?) 对于未跟踪？ 我不喜欢 A 因为它有不同的含义
git 比这里的意思，至少在我看来。

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/Microsoft/vscode/issues/178#issuecomment-339084261 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AJHVkJJNzw89umFiPB0BmgQAZYJNXTHzks5svip7gaJpZM4GlYyH
.

公平地说，它应该是不可知论的。 但是“版本控制系统未知”作为 ? 我感觉合理。 但是 N（对于 New）也可以工作，而且我想不出任何超载，尽管我相信其他人会这样做。

是的， @jrieken ，非常感谢您的努力！ 看起来真的很好！ 微妙的徽章是一个加号。

我和@WadeShuler和@petkahl一起想把 U 改成别的东西。 'N' 或 '?' 工作。 但是，我倾向于 N，因为它会是“新的”和“修改的”。

很高兴看到这一点！

workbench.colorCustomizations.git.color.ignored对每个人都有效吗？
我在1.18.0-insider上次更新是今天，被忽略的颜色仍然没有被拾取。 此外，似乎“_deleted_”和“_conflict_”还不起作用......也许明天的更新，
但困扰我的是被忽略的颜色。 文件名看起来与版本化的未修改文件相同，这意味着没有对其应用特殊颜色。
注意：屏幕截图中的 repo 没有任何跟踪文件。 所有文件都未跟踪。 一旦我从.gitignore删除 "_shared.module.ts_" ，它就会显示为棕色（我的未跟踪颜色设置）。

徽章应该是U吗？ 我认为社区应该参与进来。U 让我首先想到更新。 我知道它在 Git 术语中没有被追踪

我们之前一直在使用“U”，这不是讨论哪个更好的正确问题，但我认为 git 用户知道术语，对于其他 SCM 提供商，可以/应该使用其他字母/图标（今天就是这种情况）。

此功能尚未添加，此后我一直活跃在此线程中
它开始前进。 我从一开始就提到了“U”徽章。

这个线程是关于开发和消除整个功能，因为
这是新的。 如果字体颜色、徽章样式和徽章颜色都可以接受
要在这个线程中讨论，那么字母也是如此。

那么，除了这个线程之外，我们还在哪里使用过“U”？

那么，除了这个线程之外，我们还在哪里使用过“U”？

检查稳定的，而不是内部人员，以及使用 git 的 SCM viewlet。 它采用U代表üntracked文件。

@WadeShuler @jrieken当前的 SCM viewlet (1.17.2) 用灰色 U标记了 _untracked file_ ，用绿色 A标记了 _ added file_。 git status以ANSI 绿色显示_已添加（暂存）文件_。

所以我理解 _untracked file_ 与绿色 U的混淆。 我还预见到我的眼睛会因绿色 U与绿色 A混合而受伤。

Atom 将未跟踪和暂存的新文件都标记为green ，只要添加的文件是新文件，Xcode 就会将其标记为A。 两者都丝毫没有打扰我（但绿色的 U 确实如此）。

所以我将全部使用绿色 A s 来处理未跟踪的 _and_ 暂存新文件。

让我们继续'U' vs 'A' vs '?' https://github.com/Microsoft/vscode/issues/36912 中的讨论

我同意。 我认为最好继续使用今天界面中使用的字母。 我也不喜欢“U”，但我认为这有点超出此功能请求的范围。 如果这改变了，它应该在整个程序中改变。

好的，这是一个巨大的线程，我只有时间浏览它，所以我只想在这里说：我希望有一个设置可以禁用它。 我更喜欢所有文件名的颜色相同，当我需要查看它们的状态时，我输入git status 。 :-)

这个产品被放弃了吗？ 似乎是。

目前， list.activeSelectionForeground似乎优先于 git status 样式，因此无法看到所选文件的 git status 颜色。 我发现这些信息很有用，即使在当前选定的文件中也是如此。 当explorer.decorations.colors为真时，git status 样式是否有可能优先？
这种行为是在 Insiders 1.18 8dfa696 上观察到的。

目前， list.activeSelectionForeground 似乎优先于 git status 样式，因此无法看到所选文件的 git status 颜色。

事实上，最新的内部人士也是如此（刚刚更新）。 当我单击项目树中的文件名时，文件条目的颜色会发生变化（例如，从黄色/修改为中性）。 我也认为这是一个相当混乱的行为。 当用户点击文件时，文件的颜色不应改变。

顺便说一句，打开文件列表也有同样的问题，当你点击那里的文件时，git status 颜色被中性的选择颜色替换。

顺便说一句，打开文件列表也有同样的问题，当你点击那里的文件时，git status 颜色被中性的选择颜色替换。

嗯，这是故意做的，因为选择前景色经常与装饰颜色冲突。 添加更多颜色，如git.untrackedSelectedForeground和git.untrackedFocusedForeground对我们来说似乎不太有吸引力。 因此，当一个项目被选中并具有焦点时，我们让选择颜色获胜。

Atom 似乎没有问题....

不需要新的设置...主题将更新以适应所选项目的背景颜色是否干扰。 如果不这样做，社区将决定不使用这些主题。

我还没有检查过，但我希望“徽章”（即：U、M）不再是 svg 文件。 它们应该只是可以设置样式/着色的原始文本。

老实说，VSCode 应该为这些东西使用样式表，而不是笨拙的配置设置。 它使一个相当简单的过程过于复杂。

@WadeShuler有选择和焦点，因为我在你的屏幕截图中看到了一个编辑器光标，我相信你的项目只是被选中，而不是聚焦。 事实上，我没有看到选定和聚焦之间的 Atom 差异。 这就是它在 VS Code 中的样子

选择但不专注

选择和专注

@jrieken我已经仔细检查过，在我的 Atom 中，selected vs yellow字体颜色。 在您的第二个屏幕截图中， red颜色从test.foo丢失，这是问题所在。

我已经尝试了默认的暗色和浅色 Atom 主题，以及大约 3 个其他主题。 我的默认（如你在我的 SS 中看到的）是 Seti（UI 和主题）。 无论我做什么，我都无法让 Atom 从文件资源管理器中删除yellow颜色。 原子版本 1.21.2。

已选

精选&专注

开箱即用，VS Code 应该保留 git 状态颜色，而不管选择或聚焦状态如何。

如果您的问题是主题，那不是您的问题。 这是主题开发人员的责任来更新和适应。

旁注：我没有查看最新的内部人员或查看代码，但是git ignored文件应该使用opacity而不是字体颜色，所以它总是x无论颜色如何，都比普通文件更暗。

@WadeShuler感谢您对主题经理应如何处理其业务的反馈！ VSCode 团队怎么敢提供 API 来帮助他们做到这一点？ 那些懒惰的开发者！

@fernandofleury没有人说过不为主题管理器提供 API 来管理它。 我的帖子什么也没说。 所以你的尖刻评论，根本是无效和毫无根据的。

@jrieken说：

嗯，这是故意做的，因为选择前景色经常与装饰颜色冲突。

我说：

如果您的问题是主题，那不是您的问题。 这是主题开发人员的责任来更新和适应。

问题将是文件/文件夹树项（正常、选定、聚焦）的前景（实际上，它是背景颜色）颜色与各种 git 状态的字体颜色选择之间的冲突。

这_将_是主题开发人员的责任。 他们应该选择树中项目的前景色和各种 git 状态的字体颜色，以免它们发生冲突。

例如：一个主题开发者拥有 ThemeX 并且他的资源管理器文件树中项目的字体颜色是yellow 。 好吧，他的默认字体颜色会与默认的yellow git status 颜色冲突。 您将无法分辨哪些文件被修改了。 所以这将是主题开发者的责任！ -- 资源管理器文件树中选定/选定焦点项目的背景颜色与 git 状态的字体颜色相同。

现在延期了吗？

@IljaDaderko我不这么认为，因为它出现在即将发布的下一个稳定版本的

@IljaDaderko VSCode v1.18已经发布，其中包括此处讨论的更改。

忽略的文件颜色是否应该是 v1.18 更新的一部分？ 文档说gitDecoration.ignoredResourceForeground可用于为忽略的文件着色，但到目前为止我还没有看到它影响任何东西。 不过，修改/未跟踪的着色效果很好。 这是在稳定的 1.18.0 窗口上。

在这里相同（关于被忽略的颜色）。 也没有为我工作，因为整个 Git 实现开始了。 使用内部人员。
gitDecoration.ignoredResourceForeground所做的只是忽略着色中被忽略的文件:)

它对我有用，而且看起来很壮观。

终于到了🥇🥇

@arxpoetica这就是我得到的：

它如何适用于某些人而不适用于其他人，我不明白。 这只是一个设置gitDecoration.ignoredResourceForeground
我是唯一一个它不起作用的人吗？ 真的没有其他人吗？ :) 哦，还有@Shurelia
有没有其他人（我们，用户）在说它有效之前实际测试过设置被忽略的颜色？

操作系统：Windows 10 PRO (1709)
VSCode：1.19.0-insider（刚刚更新）
在我的工作笔记本电脑和家用台式机上也是如此。

是在 Insiders 中吗？ 我怎样才能使用它？

恭喜大家！

@nkkollaw在 😎 内部人员和稳定 (1.18)

@MrCroft请在此处讨论 git-ignore 问题： https :

由于我们在最新的稳定版本中提供了此功能，因此是时候关闭并锁定此问题了。 请为主题讨论和错误报告创建新问题。 围绕该区域的问题用file-decorations标签进行标记。

各位，感谢让这个功能成为现实的伟大而持续的反馈！

总结并重复我之前的评论。

几件事

• 默认情况下，有 color 和 bagde 的组合。
  
  
  
  • 启用/禁用图标： "explorer.decorations.badges": true|false
  
  
  • 使用"explorer.decorations.colors": true|false启用/禁用颜色
  
  
• 颜色显示在文件树、打开的编辑器部分和 SCM 视图中
• 一开始有三种颜色。 您可以在workbench.colorCustomizations设置中自定义它们。 颜色是gitDecoration.modifiedResourceForeground ，
  gitDecoration.deletedResourceForeground ,
  gitDecoration.untrackedResourceForeground ,
  gitDecoration.ignoredResourceForeground ，和
  gitDecoration.conflictingResourceForeground