• 1

これが何らかの形で拡張機能として公開されていれば、かっこいいでしょう。 場合によっては、木が少し色で汚れていて、クリスマスツリーのように見えることがあるのではないかと心配しています。 または、そうでない場合は、少なくともオンとオフを切り替えるオプションがあります。

はい私は同意する。 これを拡張APIで公開するために、別の問題を作成しました（＃1394を参照）。

+1

それも大好きです。 Gitタブは非常に便利ですが、これは別の目的です。Atomのような色を使用すると、何がどこで変更されたかを一目で確認できます（色は自動的に最上位ディレクトリまで伝播します）。 それはおそらく私がAtomから最も見逃している機能です。

通常、数十または数百の変更されたファイルがコミットされていないため、クリスマスツリーのように見える可能性は低いです:)

したがって、このPRは終了したようです。 @bpasero @ joaomoreno-この作業のステータスに関する更新はありますか？

これを確認してくださいhttps://github.com/Microsoft/vscode/pull/8462

更新なし...

この問題に関心をお寄せいただき、ありがとうございます。 現在、バックログに割り当てられています。 毎月、バックログからアイテムを選択して、現在の反復を計画します。 詳細については、 https：//github.com/Microsoft/vscode/wiki/Issue-Tracking#planningを参照して

私たちは開発者の小さなチームであるため、1つのマイルストーンで取り組むことができる機能の要求と問題は非常に多くあります。 それでも、プルリクエストはいつでも歓迎し、品質基準を満たしていれば喜んで受け入れます。

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1書き込みを停止してください。 問題のすべての人にメールを送信します。 最初のコメントに絵文字の反応を使用します。

+1

こんにちは、この機能リクエストについて何かニュースはありますか？ 私は今日vscodeを使い始めました、そして私はすでに愛しています、しかし私は本当に変化を示す色が恋しいです
おめでとうございます

+1

これを実装する際は、 206を考慮してください。

役立つスクリーンショットをいくつか追加します。

Atomのデフォルト：

VSCodeのデフォルト：

+1

+1

これは非常に便利です。

ファイルとアイコンがファイルツリーにリストされる方法を変更する機能はすでにあります。
この拡張機能はそれを行います
https://github.com/robertohuertasm/vscode-icons。

ただし、ファイル名は色付けされません

+1

+1

何か変更はありますか？ この機能により、Atomからの移動が停止します。 :(

VSCのパフォーマンスがはるかに良くなったので、私はAtomから離れました。 しかし、これは私がVSCで見逃している贅沢な機能です。

+1

これを拡張機能ではなく組み込み設定（例： git.colorExplorer ）として使用するとよいと思います。

@arkonそのような拡張機能はありますか？ 何も見つかりませんでした。

ほとんどの場合、ファイルエクスプローラーにはそれを変更するためのAPIがありません
gitの変更に。 拡張機能は私にとっては問題ありません。

金、2017年2月3日には、午前7時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など：最初の投稿の親指を立てるアイコンをクリックして、この機能をリクエストしている開発者を表示します。 彼らは問題を親指で並べ替えて、どの機能リクエストが最も人気があるかを判断します。

この種の問題の並べ替えからわかるように、この問題は現在3番目に要求されている機能です。

いいぞ。 最近Atomからやって来ました。すぐにVSCodeで見たいです！

ああありがとう@joaomoreno！

FileExplorerだけでなく、同じcoloring / qitステータスをQuickOpenに追加してください。
このようにして、ファイルを開くことは、すでに変更されたファイルに基づいて視覚的にフィルタリングできます。

これで何が起こっているのですか？ メンテナが@joaomorenoPRをマージしないのはなぜですか？ 今使用できるプラグインはありますか？ これはばかげた計画です

@SOSANA PRとはどういう意味か

2824はこれを修正するための扉を開くので、もう少し我慢してください。

@SOSANAは問題であり、PRではありません🤣

+1この機能は生産性にとって素晴らしいでしょう

+1

@ publiclass1 @ hevans90、...（+1とコメントした他のすべての人を挿入）...、あなたはこの機能が欲しいどれだけについての記事ではないコメントをしてください。 これは、GitHubが絵文字反応を追加したものです。 元のコメントを高く評価するだけです。 そうすれば、意図したとおりに電子メール通知を使用できるようになります（この問題の進行状況について最新情報を入手してください。世界中の誰もがこれを望んでいるわけではありません）。 スパムを送ってくれてすみません。 より多くの人々が+1 ingの問題を止めることを学ぶことを心から願っています。

+1

私はPhpStormを使用していますが、すべてにVSCodeを使用したいと思います。 私は現在、できるだけ多くのVSCodeウィンドウを使用しています。 私はPhpStormの色を好む/知っているので、最終的にこのカラーリングシステムをオプションとして使用していただけませんか。 参考のために：

黒-最新-ファイルは変更されていません。
灰色-削除済み-ファイルはリポジトリからの削除がスケジュールされています。
青-変更済み-ファイルは最後の同期以降に変更されました。
緑-追加-ファイルはリポジトリへの追加がスケジュールされています。
茶色-不明-ファイルはローカルに存在しますが、リポジトリになく、追加するようにスケジュールされていません。

https://www.jetbrains.com/help/phpstorm/2016.3/file-status-highlights.html経由など。 君たちはロック、ありがとう。

と

• 競合でマージされたファイルは赤で表示されますが、

競合するものを他のものと区別するのは非常に便利です

+1 Git <> Explorerビューを切り替える必要があるのは非常に非生産的です。

理想的には、変更セットを、開いているファイルがあるグループとして表示したり、色で視覚化された変更のネストされたツリーを表示したりすることもできます（上記の

一人来て、+ 1で止めてください。

最初の投稿に親指を立ててください。

プラグインが個々のファイルやフォルダーに色を付けることができる汎用APIを作成するための興味深いユースケースと引数があります。

Trelloエージングパワーアップと同様のファイル/フォルダーエージング-長い間触れられていない（git履歴で判断される）ファイルとフォルダーをフェードアウトして、「ワーキングセット」をより明確にし、見つけやすい。

理由：小さなプロジェクトの大規模なリポジトリがあり（分析レポート用のスクリプトの束を考えてください）、作業の90％以上が再び変更されることはありません（ただし、古いものをサブフォルダーに移動することはできません。レポを指すリンク）。

ツリーアイテムに色を付けるためのAPIエンドポイントがあれば、gitログを読み取り、いくつかのルールセットに従って各ファイル/フォルダーに色を付けるプラグインを作成できます。

では、これに対する拡張機能を作成できるAPIはまだありませんか、それとも統合機能として実装されますか？

これに関する更新はありますか？

+1

+1

+1

メールの受信トレイを+1してスパムを送信するのをやめてください。

それはまったく目的を果たしません。

スパムを送信しないxDに+1

protip：本文が「+1」に等しい/一致する/ lolwutsであるgithubからのメッセージを除外します

これらの人々を止めることはできません。

@fredrikaverpilとして@jmbelloteauはVSCodeの問題は元のコメントまで親指の番号でソートされ、以前のコメントで述べました。 したがって、最初のコメントにリアクションを追加する代わりに「+1」をコメントすることは、フィードバックを提供する正しい方法ではなく、すべての人に役に立たない電子メールを送信するだけなので、確かにスパムです。 そして、反応を追加するのとは反対に、それは考慮されません。

+1

私はWebstormでもこれにとても慣れています：D。 しかし、私が見ることができるように、これはおそらく遅かれ早かれ開発されるでしょう。 これはインスピレーションを得るためのWebstormのスクリーンショットです（@abdonrdに続く）：

ああ、追跡されていないファイルも赤で表示されます！

+1

今日初めてVSコードを試してみました（Atomからのもの）。私が最初に検索した拡張機能の1つは、エクスプローラービューでの「gitstatus」の強調表示でした。 「ソース管理」タブ自体は非常に便利ですが、フォルダ/ファイルを強調表示すると、ディレクトリツリーを常に展開したままにすることなく、作業中のコンポーネントにすばやく移動できます（より深くネストされた構造を持つ）。

理想的には、色を個別に変更できると便利です。

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

+1

私はしばらくの間、水を飲むことを思い出させる良いアプリを探していました。
すると、このスレッドを購読していることに気づきました。
+1を続けてください、彼らはもう役に立たないわけではありません🚰

@mmazzarolo
なぜあなたは水を飲むためにリマインダーが必要ですか？ 喉が渇いたら飲むだけでは足りませんか？

とにかく、+ 1をやめてください。 開発者はすでにこれを認識しており、更新があれば投稿する予定です。

@pohmelieそれは有効な代替手段です、ありがとう！

+1

wtfはこれらの+1人と間違っていますか？

素晴らしいアイデア、@ davidhu2000！ git.ignoredFileColor: '#333333'ような16進色もサポートすると便利です。

JetBrainsが使用するタイプと色の素晴らしいリストがここにあります： https ：

+1この機能がどれだけ必要かについての意識を高める

私がVSCodeを使用していない唯一の理由。 残念な ：（

コードベースのどこからこれを実装し始めることができるか知っている人はいますか？ 刺したいです。

@admosity昨年、誰かがプルリクエストを送信しましたが、拒否されました： https ：

2824は、少し前にマージされた上記のどこかでブロッカーとして言及されました。 そこでの変更を見て、VSチームが望む方法で実装されていることを確認します。

@AndreasGassmann素晴らしい！ 見ていきます。

最後の1つの重要な機能により、vscodeに切り替えることができません。

この機能が組み込まれると、vscodeに変更します

進捗状況を知りたいので、この号を購読しています。
誰もがこの機能がどれほど望まれているかを知っており、今のところ2番目に賛成の問題です:)。

本当にこの機能が必要な場合は、最初のコメントに賛成票を投じ、繰り返しコメントを追加しないようにします。

この機能がVSCodeに切り替える必要があると感じている人のために。 これは、Atomから切り替えたときに最初に見逃した機能だったと言えますが、IMOは、この素晴らしいIDEに支払う低価格です。
さらに、先週、Atomでいくつかの作業を行う必要があり、VSCodeのgitビューを本当に見逃していました。

@waderyanこれはアトムから移行するディールブレイカーです。

はい、お願いします！

+1

+1

+1

workbench.main.jsを変更し、 git status出力に基づいてCSSを挿入することで、この機能を実装する非常に醜いハックを作成しました。 VS Codeの内部ファイルを調べて、VS Codeに5秒ごとにgit status実行させてもかまわない場合は、ご覧ください。

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

アップデート28.6.2017：プロジェクトを再度開いたときにプラグインが読み込まれないバグを修正しました。
アップデート30.6.2017 :( Atomと同様に）変更されたファイルの親ディレクトリの強調表示を追加しました。
アップデート1.7.2017：ファイルの照合が完全なファイルまたはディレクトリパスを使用して行われるようになりました。 この変更の前に、別の変更されたディレクトリと同じ名前のディレクトリが強調表示されていました。

こんにちは、
この機能が実装されているかどうかわかりませんか？
設定も拡張機能も見つかりませんでした。これは2年近く前に開かれたので、混乱しています。

@sanjibukaiこの問題はまだ未解決であるため、まだ実装されていません。 ただし、 @ karabaja4が上のコメントで作成したハックを使用できます。

私はここで新しいですが、この明らかな機能を追加するのに本当に2年近くかかるのでしょうか。
意外にも最近までvscodeについて聞いたことがありませんでしたが、それについて聞いたとき、提唱された主な機能は、vscodeがgitをうまく統合する方法です。 そして確かにそれは良いことです。
この機能がまだ欠けているのはなんと残念なことでしょう。
それでも、良い仕事を続けてくださいvscodeチーム👍

この機能なしでは集中し続けることはできません。 編集するファイルを覚えておく必要があるたびに。

+1

@ karabaja4ハックでPRをして、それを適切に実装する方法についてフィードバックをもらいませんか？

@saadaそのコードのいずれかをgit statusプロセスを実行することは、この機能を実装するための正しい方法ではありません。 これを実装する適切なコードは、最初から作成し、VSCodeソースフレームワーク内に正しく実装する必要があります。 それは大変な作業であり、残念ながら現時点では十分な時間がありません。 ごめん ：（

記載されている指標が、返信ではなく、元の投稿が取得した+1の数であるとすでに言われている場合、積み重ねても問題は解決しません。 また、これが開発者向けのツールであることを考えると、ここで行われているオープンソースプロセスを理解しておらず、どれだけの資格があるかに少し驚いています。 機能リクエストは未解決の問題としてここにあります。 投稿で+1して、自分で（おそらく、メンテナと協力して無駄にならないように）マージを要求するか、そのままにしておくことができます。 それがあなたにとって重要な機能である場合は、Atomを使用してください。 私がこれを書いているとき、4000以上の未解決の問題があります。 あなたは忍耐を行使する必要があります。

（または、その間に@ karabaja4ハックを使用してください-あなたの仕事に感謝します！）

+1
これを行うのは、 devchatの話を聞くだけで、コメントが多い問題がより注目されるからです。

@ karabaja4お疲れ様でした。 別のアプローチ：initでgit statusを実行し、 onFileSaveイベントが発生するたびに更新するのはどうですか？ これはより効率的でしょうか？

おそらく、gitステータスを更新する方法を構成できます。

+1これは追加すると非常に役立ちます

@Kaijunどうやって実装すればいいのかわかりません。 onFileSaveイベントはどこから来るのでしょうか？

それがドキュメント保存時のコードからのものである場合（私がそれに添付する方法を知っていると仮定して）、ファイルの移動やコピーなどの変更と同様に、コードの外部で変更されたファイルは無視されます。

ソリューションツリーに実装されているフォルダー監視ロジックからのものである場合、これはツリー全体に対して再帰的に実行する必要があります。 パフォーマンス面で価値があるかどうかはわかりません。

@ karabaja4コードは外部の変更も検出すると思います。 したがって、デバウンスシステムを使用してこのような「イベント」にフックすると、同じ間隔で複数のファイルが変更されても、複数のgitステータスチェックがトリガーされなくなります。 これはうまくいくかもしれません！ おそらく、fsピースに精通している誰かがチャイムを鳴らすことができますか？

これは本当にバックログにあるべきではありません。 この一見小さな機能を追加することには、非常に現実的な価値があります。 開発者の幸せは道を進んでいます。 この問題を見てがっかりするのは何千もの+1であり、2015年以降無視されています。

@kamok本当です！ Atomは遅いですが、別のオプションがありました... WebStormに戻りました。これは、Gitに加えて、vscodeに拡張機能をインストールする必要がある他の機能と統合する方法で無敗であり、それでも非常に高速です。速度の点では、IDEというよりも軽量のエディターのように見えます。 この機能だけでは（ファイルエクスプローラーのGitステータス）、vscodeユーザーを維持するにはまだ十分ではありません。 これはバケツのほんの一滴になります。 これは、WebStormから提供された、私が最も見逃していない機能です。
vscodeチームは、JetBrainsのメンバーがどのようにそれを行っているかを確認することをお勧めします。
申し訳ありませんが、試してみました...何ヶ月もvscodeに苦労し、更新後の更新を待っていましたが、それでも常にvscodeを閉じて、WebStormでプロジェクトを再度開いています：エクスプローラーのGitステータスツリー、スタッシュ、ローカル変更用のフォルダー/ツリービュー、ブランチの比較、右クリック>クリップボードとの比較...そしてこれらは私の頭のすぐ上にあります。 Vscode Gitの統合には、開発者を本当に支援したいのであれば、まだ道のりが遠いです。

使用して私のサムスンSM-G950Fから_Sent FastHubを_

@MrCroft作業方法が非常に心配な場合は、チームに直接連絡することをお勧めします。それ以外の場合は、問題を高く評価して+1し、気になる場合は編集者を切り替えます。

@cucumbur私はすでにしました（vscodeから切り替えました）。 vscodeがどのように感じられるかが本当に好きだったので、私はただ悲しみを述べています。 使い続けることができるように、Gitがうまく統合されていればよかったと思います。 多くの人が同じように感じていると思います。
私はまだそれを監視します。 たぶん、「それほど遠くない将来」にそれが行われることを知っているでしょう... vscodeを除いて、私は実際にはマイクロソフトの大ファンです...ソフトウェアとハ​​ードウェア、彼らは10回のうち9回非常に高品質のものを構築します。 vscodeが9の1つになることを願っています。

使用して私のサムスンSM-G950Fから_Sent FastHubを_

@kamokすべての新しい問題はバックログに入り、対処されるまでそこにとどまります。 この機能はまったく無視されていないと思います。 それはあなたが思っているよりも多くの変更を必要とするだけです。 私の知る限り、彼らはこれを拡張APIの一部にしたいと考えており、現在、ファイルツリーにはこれを実現するための多くの機能がありません。

問題を親指で並べ替えると、この問題が2番目に人気のある問題であることがわかります。最初の問題は作業中であり、ほぼ完了しています。 もう1つが完了するとすぐに、彼らはこれに取り組み始めると確信しています。

ただし、このスレッドをときどき更新するのは素晴らしいことです。

アトムから切り替えましたが、更新されたファイルが強調表示されていない大規模なプロジェクトでは、作業が困難になります。
この機能が利用可能になるまでAtomに切り替えます

おそらく、私にとって有効な代替/暫定的な解決策は、「エディターを開く」ビューでツリー構造を複製することです。 通常、ビューには「更新された」ファイルが表示されますが、プロジェクト内のどこにこれらのファイルがあるかが明確であるかどうかとは対照的に、ファイル名のダンプだけを操作するのは非常に困難です。

これに関する更新はありますか？

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

私はマゾヒスティックに👎私自身のコメントです。

VSCodeを試し続けていますが、この機能が不足しているため、切り替えることができません。 切り替えようとするまで、Atomでこの機能にどれだけ依存しているかに気づきませんでした。

これがatomからVScodeに切り替わるのを待っているだけで、すぐに実装されることを願っています。

+1

2年が経ちました。

そして驚くべきことに、あなたのコメントはそれを変えることにはなりませんでした。 開発と潜在的な貢献を気にする私たちの人々はあなたの問題のスレッドを購読します、あなたのコメントは何の役にも立たず、99人に役に立たない電子メールを送ります

やってみないと結果が出ないですよね？

最初はとても見逃していました。持っていると非常に便利ですが、「diffexplorer」（垂直メニューの3番目のアイコン）は非常に強力で、非常に便利です。

+1
これが実装されていれば素晴らしいでしょう...！

ハックのインストールを簡素化するgulpタスクを作成しました（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、VSCode1.15.1で私のために働いています。

@ karabaja4ありがとう！ ここでFedora26、VSCode1.15.0で作業しています。 それだけで、Atomからの切り替えがはるかに便利になりました。

@ karabaja4 + 1ありがとう!! Ubuntu 14.04 64、VSCode 1.15.1（手動インストール）で私のために働いています

+1

@ karabaja4 + 1これはすごい。

+1

@mattiプラス1

使用arm64のための私のHTC MSM8996から_Sent FastHubを_

@ibrokemypieマイナス2

Lolbugを使用してarm32用のHTCMKB826262から送信されました

この機能に関するニュースはありますか？

+1

+1

+1

@ karabaja4ありがとう男= D <3

+1

うわー、これは2年前に実装されるべきでした

@eosrei +1

+1

+1
現実に直面しましょう。 私はVSCodeが大好きですが、Gitタブは本当にひどいです

@ karabaja4こんにちは、1.16がリリースされました。このリリースでハックを移植しますか？ ありがとう。

編集：マルチルートワークスペースを使用している場合ではなく、1.16で動作します。

@karabaja4👍

@ karabaja4はちょうど私の日を作りました。 ありがとう！

+1

+1

+1コメントは、GitHubの問題を自動的に禁止する必要があります...

GitHubが+1の投稿を解析し、元の投稿に対する親指を立てる絵文字の反応に自動的に置き換えた場合は、より良いでしょう。

@ karabaja4あなたのハックは

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に1時間戻って、最新のideアップデートを使用しました。ファイルツリービューに色付きのファイルがあるので、私の生活はとても簡単だと思いました。

編集：回避策が見つかりました。 vsコードファイルの1つに行を追加する（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

この情報に違反し、他の人がこの通知を受け取ったことをお詫びします。

他のスレッドで、Microsoftが機能の優先度を+1コメントの数で評価していることを読みました。 これが間違っていて、機能のランク付け方法がまったくわからない場合は、お詫び申し上げます。 コメントを削除しました。 いずれにせよ、攻撃的な態度の仲間とは何ですか？ あなたはより良いトーンで同じことを指摘することができた@leocaseiro

乾杯。

こんにちは@aecorredor 、失礼に聞こえた場合はお詫び申し上げます。
私は英語を母国語としないので、翻訳された表現の1つが悪いように聞こえたのかもしれません。 そのコメントの説明を改善するのを手伝ってください。 迷惑という言葉を置き換える必要がありますか？ 使い物にならない？ ありがとう。

PS：失礼に聞こえたかもしれないので、あなたが私のメールで読んだ世界を編集してくれてうれしいですが、誰かを怒らせるつもりはありませんでした。

更新：以前のコメントを置き換えました。音が良くなった場合はお知らせください。 ありがとう

ねえ@leocaseiro 、

そもそもその悪い言葉を書いてすみません。 私は実際に気づきました
言語の壁がおそらく混乱を引き起こしていたのだと。 しかし
ええ、私はこれらの2つの単語を次の行に沿った何かに置き換えます。
「お願いします、私たちは皆、全体的なgithubエクスペリエンスを改善しようとしています
未解決の問題/機能のリクエスト、そして人々が使い始めたらいいのに
「+1」のようなコメントの代わりに絵文字の反応
スレッドに不要なオーバーヘッドがあり、実際にはそうではない電子メールをトリガーします
意味のある方法で貢献します。 方法については、このリンクを参照してください
絵文字の反応は機能します：{ここにリンク}

乾杯、そしてハードな気持ちはありません。

ベスト。

23:44時月、2017年9月18日には、レオCaseiro [email protected]
書きました：

こんにちは@aecorredorhttps ：//github.com/aecorredor 、聞こえたらお詫びし
失礼。
私は英語を母国語としないので、おそらく私の翻訳者の1人です
表現が悪そうだった。 の説明を改善するのを手伝ってください
そのコメント。 迷惑という言葉を置き換える必要がありますか？ 使い物にならない？ ありがとう。

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が現れました😁。

プログラマーはエラーメッセージを読んでいないことでユーザーを非難することがよくありますが、コメントや指示を読むことができないので、それは残念です。

おそらく、+ 1をコメントする代わりに、ユーザーにリアクションを使用するように求めるために、README.mdに何かを置く価値がありますか？ たぶんCONTRIBUTING.mdでは少し隠されています。

わかりません。登録を解除して、準備ができたらリリースノートを待つだけだと思います。

私はこれを処理する要点を作成しました。 @ karabaja4による修正では、無視されたファイル/フォルダーが適切にグレー表示されません（彼の問題を参照）。 マージされなかった

したがって、これをもっとうまく機能させたい場合は、私の要点を確認してください： //gist.github.com/WadeShuler/1637073371ad126779076344c34278f3

@ikatyang ：申し訳ありませんが、それはこの機能が10月（2017）に導入されることを意味しますか？

@nkkollawリンクはこのコメントからのものhttps ：

コメントは、「反復計画」ではなく、ここでこの問題に関連することを議論することを求めているだけでした（そしてそれらを英語で議論することを求めていました）。

ああ、 @ tiangolo 、ありがとう。

この機能を実装するためのAPIができるまで、Atomに我慢しようとします（申し訳ありませんが、これを支援するのに十分ではありません）。

私はプロジェクト自体の中で更新を行うことに取り組んでいます。
今のところ、機能している概念実証を作成しましたが、すべてを適切な場所に配置するためにレイヤーを理解する必要があるため、tslintを通過しません。
ここにいくつかの更新を入れます。誰かが私を助けたいと思ったら、後でプルリクエストへのリンクを入れますので、助けてください。

2017年10月のイテレーションを予定!! 👍

これの最初のバージョンがあります。 これは10月に来るので誰もが安心します。

もう少し情報：

• 色はテーマで定義されます。つまり、好みに合わせて色を調整できます。
• これを有効/無効にする設定があります
• これはバージョン管理に限定されません。 また、ファイルエクスプローラー（＃782を参照）でエラー/警告を強調表示することも検討しており、これを拡張機能の作成者に公開することを検討しています。

未解決の質問：

• 色だけで十分ですか？ テキストやアイコンのヒントも必要ですか？
• 親はどの子ステータスを取得する必要がありますか？ これは重要になりますか？ エラーや警告があれば簡単ですが、より重要なのは、変更されたファイル、追跡されていないファイル、または無視されたファイルですか？
• これらのファイル装飾を「OpenEditors」バケットやファイルピッカーなどにも表示する必要がありますか？

何かが起こっている間、私はこの問題を最新の状態に保ちます。 いつものように、「+ 1」の代わりに感情を使用してください-コメント。 おかげで、ハッピーコーディング！

個人的には、上の画像にあるもので十分です。 見栄えが良く、ありがとう！

濃い灰色の.gitignoreによって無視されたファイルを見逃しているようですか？

内部の無視されたファイルだけの親フォルダーの色（グレーアウト）を変更することはありません。 フォルダ自体が無視された場合にのみグレー表示されます。 私のコメントを参照してください/いくつかのコメントを修正してください。 Gitにステータスをダンプさせ、それがディレクトリかファイルかを検出します。 ファイルツリーのファイル/フォルダにクラスを追加するだけで機能します...「git-status-modified」や「git-status-added」など。 その後、テーマは魔法を働かせることができます。

皆さんが取り組んでいることを私たちに引っ張らせてくれればいいのですが、そうすれば私たちはそれで遊んで、PRを作成することができます。 正直なところ、それが台無しになった場合、実行可能な解決策が妥当な時間内に達成できない場合、人々はおそらくコードの使用をやめるでしょう。 多くの人（私を含む）が同様の問題のためにAtomを離れました。

また、エラーがある場合は、ツリー内のファイル名の前後にドットを使用すると思います。 これは目立たず、テーマにスタイルを設定させ、Gitの色の強調表示を妨げません。

はい、これは拡張機能の開発者に公開する必要があります。 すでに行われているはずです。 クールな拡張機能を作成したり、皆さんがしなかったことを修正したりするために、ファイルツリーを制御したくないのはなぜですか？

濃い灰色の.gitignoreによって無視されたファイルを見逃しているようですか？

確かに、それは進行中の作業であり、物事は一度に1つずつ起こります。 無視されたファイルも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 ：あなたが何について話しているのかわかりません。

無視されたファイルとその子をグレー表示する必要があることを指摘しました。この定義では、無視されたファイルの親をグレー表示する必要がないことは明らかです。

はどうかと言うと：

あなたの受動的攻撃的メッセージは、このスレッドを役に立たないメッセージで詰まらせているだけです...

私のメッセージがどのように受動的攻撃的であったかはわかりません—それが何を意味するのかわからないと思います—しかし、私のメッセージの後にコメントしたのはあなただけなので、このスレッドを詰まらせているのはあなたです。

変。

うわー..良いアイデア！ それはいいですね！

右の列に1文字のテキストヒントのような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/だけでなく、具体的にはランダムな名前のアセットdirです。 内容が無視されるディレクトリを処理する場合、無視されるファイルをすべて指定する必要はありません。 vendorまたはnode_modulesディレクトリなど。 git status無視されたエントリには1つのエントリしかありません。

ファイルツリーで、 backend/web/assets/6f57f06b/で始まるすべての要素（ファイルとフォルダー）にgit-status-ignoredクラスを追加する必要があります。

ファイルツリーフォルダ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番目のルールでは、すべてのタイトルを^=と一致させるため、文字列の先頭で、それよりも深いすべて（すべての子）と一致します。

ディレクトリを照合するには、2つのCSSルールが必要です。 したがって、これを実行している間、ディレクトリのHTML要素にtitleして、末尾にスラッシュを含める必要があると思います。 このスクリーンショットで私が話していることを見ることができます：

はい、あなたのコメントは受動的攻撃的でした。あなたは実際に言葉を言わずに失礼/スナーク/くだらないことをしていたからです。 さらに、あなたは間違っていました。 誰も子供について何も言わなかったし、それは私たちが話していたことでもない。

@jrieken
Atomのセットアップの仕組み：「編集済み」は「追加済み」よりも優先されます。 ファイルを削除してもステータスは表示されません。 「ステージング済み」のステータスはありません。 他の人は自分のAtomセットアップをチェックして、これが自分にも当てはまるかどうか、そしてそれが私のセットアップだけではないかどうかを確認する必要があると思います。 あらゆる状況に対応するコードを追加し、ユーザーが希望どおりに機能するようにコードを編集できるようにするとよいでしょう。

たぶん、複数のクラスを追加するので、ツリーの一番上にある親ディレクトリには、「git-status-added」と「gitstatus-modified」があります。 その下で何かが削除された場合は、「git-status-deleted」を投げ込むことさえできます。

次に、cssを使用してそれらを一致させます。 .git-status-added.git-status-modifiedに別の色が必要な場合は、緑色の下線付きのオレンジ色のフォントを使用できます（変更された場合はオレンジ色、追加された場合は緑色）。 .git-status-addedクラスしかない場合は、フォントを緑色にします。

クラスを追加したら、それは実際には問題ではありません。誰もが好きなようにCSSを作成できます。 ただし、箱から出してすぐに使用できる「かなり良い」デフォルトのスタイルが必要です。

時間があればその枝を引っ張ってチェックします。

lintエラーとgitステータスを処理する方法は？

Atomは、次のように、ファイル名の下に赤い波線を配置します。

lint-errorなどのクラスをgit statusと同じ要素に追加する必要があると思います。これは、私たち（およびテーマ）が独自のスタイルシートを介してオーバーライドできます。

したがって、上記の例で使用したのと同じファイルツリー内の要素のdiv（backend / web / assets / 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ステータスを適用すると、次のようになります。

<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;
}

君たちはスラックを持っていますか？ コミットには編集されたファイルがたくさんあります。 ファイルツリーにgitステータスカラーを適用している場所を正確に探しています。 /extensions/git/src/repository.tsにありますか？

みんなに感謝し、変更、追跡されていない、無視されたファイルのルールを明確にしてくれてありがとう。 明日のインサイダーはこれの初期バージョンで出荷されます。

いくつかのこと

• デフォルトでは、色とバッグの組み合わせがあります。
  
  
  
  • 次のアイコンを有効/無効にします： "explorer.decorations.badges": true|false
  
  
  • "explorer.decorations.colors": true|false色を有効/無効にします
  
  
• 色は、ファイルツリー、開いているエディターセクション、およびSCMビューレットに表示されます
• そもそも3色あります。 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インサイダーを実行しています、Windows10でf1ee80be081b0d ...をコミットします
（[バージョン情報]ダイアログボックスのテキストがハイライト表示され、コピーできると便利です）

これをまとめてくれてありがとう@jrieken ！

いくつかの考えがありました：

• 選択した色がステータスカラーではなく古いグレーのままであるように見えます
• アイコンを付けるかどうかのオプションに同意しました（
• アイコンが表示されている状態で、変更/更新された色が明るい場合、「M」または「U」は暗く（またはその逆）、コントラストがあり、読みやすくなります。

色を取得するためにビルドごとにmain.jsファイルを更新する必要がないことを楽しみにしています!!!

マイナーな問題（10月16日現在の最新のインサイダーを使用）、 @ jrieken ：このファイルが現在選択されている場合、プロジェクトツリー内の変更されたファイル名の色は表示されません。 ここでの期待は、ファイルがプロジェクトツリーで選択されているかどうかに関係なく、色は同じである必要があることです（変更されたファイルを示します）。

私が対処したいもう1つの問題は、プロジェクトツリーだけでなく、開いているエディターセクションでも同じ色分けであるということです。 現在、開いているエディターセクションで、どのファイルが変更され、どのファイルが変更されていないかを確認する方法はありません。 変更されたファイルのためである編集者素早く把握する能力は1つが彼/彼女はすぐに変更し、現在は修正されたファイルの名前を覚えしようとする必要がないファイル間をジャンプすることができそうという、非常に便利です。

これは素晴らしい機能です。 AtomのVSCは初めてで、とても懐かしいです。

Atomから移動したばかりで、この機能もありません。 この機能を備えたリリースはいつ予定されていますか？

同様に、gitignoredファイルはリスト内で目立ちすぎて、すべてのものと混同されるため、これは最も重要です...

こんにちは、バッジの前景色を変更するためのカラーキーも必要だと思います（＃36246）

継続的なフィードバックをありがとうございました。 最近の変更を反映するために、最初の要約コメントを更新しました。 また、設定の変更がリロードせずに反映され、ステータスの色が選択の色よりも優先されることを確認しました。

デフォルトでは、主に2つの理由から、引き続き色とバッジを使用します。色の意味を誰もがすぐに理解できるわけではなく、バッジ（ツールチップ付き）を持っていると、これが自明になる可能性があります。 第二に、実際には私のように、それらの色を区別するのが難しい人々がいます。バッジは、これをもう少しアクセスしやすくするためのものです。

@jriekenCSSクラスが左側のファイルツリーエクスプローラーの要素に適用されているかどうかを教えてください。 これにより、最高の拡張性が得られ、テーマ開発者と私たち個人が色をカスタマイズして上書きするのが簡単になります。

例：新しいコード修正でファイルまたはフォルダーが追加済みとしてマークされると、 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インサイダーをテストしました。 私は上のスレッドをざっと読んだので、1.19の作業にすでに何かがあり、以下に言及することに対処する場合はご容赦ください。

1）ファイルツリーの「追加済み」ステータスは、「U」バッジが付いた「更新済みおよびマージされていない」ように見えます。 追加されたファイルには「A」バッジが必要です。

2） git.color.addedカラーオプションはありません

3） git.color.ignoredカラーオプションはありません。

4）（グリッチ）「追加された」ファイルを「追跡されていない」ものとして扱います。 「追加された」ファイルを調べたところ、htmlのように見え、追跡されていないと思われます。 （ spanタイトルは「追跡されていない」と表示され、クラスはmonaco-decorations-style-32 、「U」アイコンです）。 これは、 workbench.colorCustomizationsの色をgit.color.untrackedに変更すると明らかです。これは、「追加された」ファイルを制御するためです。

5）「名前変更」または移動の「R」ステータスをサポートし、「R」バッジを追加し、一致するgit.color.renamed設定を追加します。

ありがとう、1.19を試すのを楽しみにしています👍

@ danjjl ＃7829の保留中のPRがあります。これを適用すると、gitサブモジュールは色を取得します。

サブモジュールが変更された場合、それ（サブモジュールのルートであるディレクトリ）がメインのgitリポジトリのディレクトリステータスの色として扱われるのか、それとも別の色として扱われるのかわからないという潜在的な問題があります含まれているファイルに基づく色。

つまり、サブモジュールディレクトリの色が、親ディレクトリの「git status」に基づいているのか、サブモジュールに基づいているのかわかりません。 とにかく問題ではないかもしれません。

@jrieken Slackグループ、またはこの問題について話し合う他の場所がありますか？ 私は助けることができます:)マスターブランチから現在の変更をプル、開発、およびデバッグすることができました。 「U」と表示される「追加」ファイルを修正し、「段階的」サポートも追加しました。 プロジェクトに参加したのは初めてだったので、マスターにリセットしてやり直します。 私はたくさんの変更を加えました、そして核兵器ではなく外科医のように行きたいです。

raw.x + raw.yチェックに続いて、 raw.xチェック、次にraw.yチェックがあるのはなぜですか？ 2つの異なるステータスに一致する原因になっているようです。

ADDED / INDEX_ADDED 、 MODIFIED / INDEX_MODIFIED 、およびその他のいくつかのステータス定数があるのはなぜですか？ さまざまなgitステータスをすべて理解していますが、Gitステータスの名前ではなく、エンドユーザーが処理するのが理にかなっています。 ADDEDは、現在UNTRACKEDとして使用しているものに使用して、設定コードgit.color.added設定する必要があります。 これらのステータス定数のいくつかは重複しているので、単純化してクリーンアップする必要があると思います。

_M <-アンダースコア=スペース/なしのgitステータスはraw.yと一致し、 INDEX_MODIFIEDます。 これは正しくありません。x=なし、y = Mのステータスは、 staged表します。

何らかの理由で、時にはランダムに、変更を反映していないようです。 また、gitステータスの変更は再帰的に上から下にスキャンしているようです。 大規模なプロジェクトがある場合は、「無視された」ステータスがフォルダ/ファイルを介して滴り落ちるのを見ることができます。 それをスピードアップするために、より深くナビゲートすることは、そのディレクトリのためにそれをキックインし、それらを灰色にするように見えました。 -このプロセスはシステム/ 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_ *がステージングされているためです。変更されるのは、ステージングされているものだけです。 INDEXをSTAGEに置き換えると、彼らが使用しているロジックは技術的には正しいものの、より理にかなっていると思います。 https://git-scm.com/docs/git-status 、特に表「XYMeaning」を参照して
（編集：フォーマットが悪かったのです。オリジナルに移動してください。半分ほど下がった赤のテーブルです。）
それは明らかに彼らがこのすべてに使用しているものです。

そして、私はあなたが_Mの場合、MODIFIED、インデックスが変更されていない（つまり、ステージングされていない）と一致するという間違いを犯していると思います。 もちろん、他の場所でこのコードの複製を見ている場合を除きます。

@petkahlありがとう、私はGit Status ShortFormatに精通しています。 私は数週間前にそれを使用して、これが正式に解決されるまで、基本的なGitステータスを追加するための

_M （アンダースコア=スペース）を取得することは（どういうわけか）可能です。 どのように、なぜ、いつ..私は今日（そして数週間前に私の要点に取り組んでいたときに）これを手に入れました：

➜  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/

要旨の研究をしていた時、「A_」と「_M」を上演することは可能だと思いました。 また、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/

では、これには「[S] [M]」という2つのバッジが必要ですか？ ステージングしたファイルを知りたいです。 さくらんぼ狩りに便利です。 ステージングされたファイルを変更したかどうかを確認すると便利な場合があります。 少なくとも段階的なバッジが必要です。

@WadeShulerコミットして変更することで、一貫して_Mを取得できます。 つまり、インデックスでは変更されていません（_ =スペース）が、作業ツリーでは変更されています。
それで：
ファイルの作成：??
git add file A_
git commit（ステータスではありませんが、スペーススペースに相当します）
ファイルを変更します：_M
git add file M_
もう一度変更してください：MM

バッジが2つある場合、私は実際には意見がありません。 通常のgitstatusと同じように、ステータスウィンドウを確認せずにチェックインすることはありません。 たぶん、どちらを優先するかを選択できる設定だけですか？ 私は両方の議論を見ることができました。 または2つのバッジだと思います。 着色も同じでしょうか？

Stagedサポートを追加しました。 ここで変更を確認できます： WadeShuler / vscode：gitstatus-fix 。 また、[Gitステータス]タブのバッジの一部を少し大きくすることで、少し見栄えを良くしました。

何らかの理由で、 vendorディレクトリの暗くする/無視することを削除しましたが、内部の内容はまだグレー表示されて無視されています。 単純な変更でvendorディレクトリのグレー表示が停止した理由がわかりません。 それが私が今やったことの唯一の問題であり、なぜ私がまだPRを発行しなかったのか...

ステージングされたファイルの色/アイコンが含まれる場合、これは間違いなくオプションである必要があります。 個人的には、リストにステージングされたものを、元の新しい/変更された色とは異なる色として見たくありません。

ステージングを含め始めると、新しい/新しいステージング/変更された/変更されたステージングされた/変更されたステージングされた変更された/新しいステージングされた変更されたなどのすべての組み合わせと順列を含める可能性があるため、すぐに複雑になる可能性があります。 、これは色と混乱の巨大なマトリックスにつながります。

私たちは問題を過度に複雑にしないと投票します。

@dseippに同意します。 これが、ステージングされたファイルに色を付ける必要がないため、最初のハックでステージングされたファイルのサポートをマージしなかった正確な理由です。

色の強調表示の目的は、ファイルエクスプローラーで一目で新しい/変更されたファイルを見つけることができるようにすることです。 私がいくつかのファイルをステージングする場合、それは通常、コミットの前であるか、そうでなければそれらを使い果たしているので、それらを通常の色にすることはできません。

考えられるすべてのタイプのgitステータスに色を追加すると、ファイルエクスプローラーはクリスマスツリーのように見え始め、実際に何が起こっているのかを確認するのは非常に混乱します。

@jriekenもう1つのバグレポートは、最新のインサイダーで発生します。

• VSCodeバージョン：コード-インサイダー1.18.0-インサイダー（82dcf9835265cd0a45ec135587ae2a82673f1c8f、2017-10-20T04：24：25.632Z）
• OSバージョン：Windows_NT x64 10.0.15063

基本的に、VS Codeは、一部のファイルが変更され、それに応じて色を付ける必要があることを時々「忘れ」ます。 たとえば、現在6つのファイルが変更されています。 VS Codeは（正しく）gitボタンに数字の「6」を表示します。 しかし、プロジェクトファイルツリーでは、黄色で表示されているファイルは1つだけで、他の5つのファイルは変更されていないように見えます。 興味深いことに、開いているエディターセクションでは、6つのファイルすべてが適切に色付けされています。

@dseippオプションの場合もあります。 ただし、ファイルをステージングするまで「ステージングされた」色は表示されません...したがって、99％の確率で表示されることはなく、実際に誰も気にする必要はありません。

@ karabaja4私はそれが

色の強調表示の目的は、ファイルエクスプローラーで一目で新しい/変更されたファイルを見つけることができるようにすることです。 私がいくつかのファイルをステージングする場合、それは通常、コミットの前であるか、そうでなければそれらを使い果たしているので、それらを通常の色にすることはできません。

したがって、この機能が追加されたとしても、気にする必要はありません...

ステージングされたファイルを表示できることは、コミットしようとしているものを選択するのに役立ちます。 100個のファイルを変更した後、それらをグループ化する必要がある場合は、ファイルツリーを調べて、ステージングされているものを簡単に確認し、見逃したファイルを見つけて、同じコミットにあることを確認できます。

一握りのファイルをコミットした後、1つを逃したことに気付いたことが何回ありますか？ 次に、2つのオプションがあります。最後のコミットを変更して、失われたファイルを含めるか、新しいコミットを作成します。 チームで作業する場合、チームを同じコミットに含める方がクリーンで混乱が少なくなります。

ステージングされた時点では、ファイルが追加されたか、変更されたか、またはその他のものであるかどうかは関係ありません。

正直なところ、Visual Studio CodeがGitを処理する方法は、気まぐれでバグが多いです。 大きなファイルツリーでは、文字通りファイル/フォルダから色が滴るのを見ることができます。 それはランダムに着色を落とします...

Gitサポートのニーズ全体が最初から書き直されたものだと思います。

また、ステージングされたファイルに色を付けることへのサポートを表明したいと思います（有効にできる限り、オプションで問題ありません）。

これが私のワークフローです：私はいくつかの機能/バグ修正に取り組み始め、それを「OKish」状態にします。つまり、コードは多かれ少なかれ機能しますが、いくつかの磨き/微調整/クリーンアップまたはリファクタリングが必要です。 その瞬間、私は自分の変更をステージングします。 次に、クリーンアップとリファクタリングを実行します。 リファクタリングが失敗したり、乱雑になりすぎたりした場合は、ステージングされた状態に戻ります。

現在変更しているファイルを確認できることは非常に有益です。変更をステージングするときに、すべての情報を失って色のないプレーンツリーに到達したくありません。

@vvsステージングされたファイルの色が失われないことについて同意します。 色はコミットされるまで残る必要があります。 ステージングされた色が新しい/変更された色を維持し、追加のステージングされた色はオプションのままであることが望ましいです。

ステージングは​​同じ色を維持できるかもしれませんが、コントラストを付けるために何らかのハイライトまたはボールドを追加するだけです。

先行技術を見ると役立つかもしれません..段階的なインジケーターを見たことを覚えていませんが、おそらく時代は変わっています

変更された/ステージングされていない/ ...ファイルのファイルエクスプローラーのアイコンは本当に必要ですか？ 注意力に問題があるので、色やアイコンで気が散りやすくなります。 それはオプションであり、デフォルトで無効にできませんでしたか？ 彼らに気を取られているのは私だけですか？

ユーザーエクスペリエンスの観点からは、少ないほうが多い場合もあり、多くの人はこれらを無効にするオプションを探すことを気にせず、苦しみ続けたり、エディターを変更したりします。 これをよく考えて、これがより良いUXに本当に必要かどうかを判断するのは良いことだと思います（これがこれらのアイコンのポイントだと思います）。

*この問題に関するすべてのコメントを読む時間がなかったので、すでに話し合ったことがあれば教えてください。できるだけ早くすべてを読んで、それに合わせます。言われたこと。 ありがとう。

これをよく考えて、これがより良いUXに本当に必要かどうかを判断するのは良いことだと思います（これがこれらのアイコンのポイントだと思います）。

https://github.com/Microsoft/vscode/issues/178#issuecomment -336960308が、デフォルトで色とバッジがある理由です。 UIが少し雑然としていて、アクセス可能/包括的であるだけでなく、滑らかでクリーンな提案を受け入れることができるようになることに同意しました。

@jriekenありがとうございます！ バッジを導入したコミットを教えていただけますか？ 私は両方の問題（色が見えない、またはそれが何のためにあるのかわからない、そして気晴らしの問題）に有益な何かを見つけようとします。

@jrieken Xcodeからページを取得して、バッジをより

バッジは初心者にヒントを与えるのに役立ちますが、色を学習すると雑然とします。

余分な自転車の脱落については、視覚的に同じ重要性があるため、 git.color.ignored （上記の_left_）で色付けされたバッジを好みます。 つまり、フェードアウトしますが、必要になった場合に備えて消えないでください。

微妙なバッジを実装する場合は、一貫性を保つためにソース管理サイドバーバッジを更新する必要があります。

バッジの議論がどの方向に進んでも、バッジのデザインは少なくともGitサイドバーのデザインと一致しているでしょうか？ Explorerサイドバー用に1つのデザインを持ち、Gitサイドバー用に別のデザインを持っているのは少しバラバラに感じます。

@jayjunからの1文字の提案が好きです。 今日はやってみます。

微妙なバッジを実装する場合は、一貫性を保つためにソース管理サイドバーバッジを更新する必要があります。

それは起こるでしょう、それは10月の私の計画にあります。

https://github.com/Microsoft/vscode/issues/178#issuecomment-335511695を最新のスクリーンショットと色の名前で更新しました。 また、明日のインサイダーでは、SCMビューレットに同じバッジを表示しますが、色付きのラベルは表示しません。 そのようです

見栄えが良い@ jrieken-継続的な努力に感謝します。 バッジの方がずっと良く見えると思います！

バッジはUがありますか？ コミュニティが加わるべきだと思います。 Uは、私に最初にupdated考えさせます。 私はそれが知っているuntracked Gitの用語では、私が思うにAことを、特に基本的な用語に慣れていない人のために、より多くのフィッティングさをU人跡未踏です。 -私は個人的にAに追加投票します。 のように、それはあなたのリポジトリに追加されました。

次に、 staged （設定でオプション）をサポートすると、かなり近いです👍

@WadeShuler 、追跡されていない場合の疑問符（？）はどうですか？ 少なくとも私の心の中では、ここで意味するものとは異なるgitの意味合いを持っているので、私はAが好きではありません。

編集：しかし、私はUが混乱する可能性があることに同意します。

疑問符で大丈夫だと思います。 しかし、私はコードがないと思います
Gitのみをサポートしますか？ 私たちはそれを視覚的に見るべきではないと思います
エディターは「Git」ですが、一般的にバージョン管理が強化されています。

いずれにせよ、私は「U」が本当に好きではありません笑

14:20ピーター・カーレで火、2017年10月24日には[email protected]
書きました：

@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と一緒に、Uを別のものに変更したいと思っています。 「N」または「？」 仕事。 しかし、私はNに傾いています。そうすると、 'N'ewと' M'odifiedになります。

これが一緒になるのを見て興奮しています！

workbench.colorCustomizations.git.color.ignoredはみんなのために働いていますか？
私は今日最後に更新された1.18.0-insiderしていますが、無視された色はまだ検出されません。 また、「_ deleted_」と「_conflict_」はまだ機能していないようです...おそらく明日のアップデートで、
しかし、私を悩ませているのは、無視された色です。 ファイル名は、バージョン管理された未変更のファイルと同じように見えます。つまり、特別な色は適用されていません。
注：スクリーンショットのリポジトリには、追跡されたファイルはありません。 すべてのファイルは追跡されていません。 .gitignoreから「_shared.module.ts_」を削除すると、茶色で表示されます（追跡されていない色の設定）。

バッジはUにする必要がありますか？ 私はコミュニティが加重するべきだと思います。Uは私に最初に更新されたと思わせます。 私はそれがGitの用語で追跡されていないことを知っています

以前は「U」を使用していましたが、これは何が良いかを議論するのに適切な問題ではありませんが、gitユーザーは用語を知っていると思います。他のSCMプロバイダーの場合、他の文字/アイコンを使用できます/使用する必要があります（今日はそうです）。

この機能は追加されていません。それ以来、私はこのスレッドで活動しています。
それは前進し始めました。 私は最初から「U」バッジについて言及しました。

このスレッドは、機能全体の開発とアイロンがけに関するものです。
それは新しい。 フォントの色、バッジのスタイル、バッジの色がすべて許容できる場合
このスレッドで議論するために、手紙もそうです。

では、このスレッド以外で、「U」を使用している場所は他にありますか？

では、このスレッド以外で、「U」を使用している場所は他にありますか？

インサイダーではなく安定したものと、gitを使用したSCMビューレットを確認してください。 これは、uは、ファイルをntrackedためにUを使用しています。

@WadeShuler @jrieken現在のSCMビューレット（1.17.2）は、_untracked file_を灰色のUでマークし、_addedfile_を緑色のAでマークします。 git statusは、 ANSIグリーンで_追加された（ステージングされた）ファイル_を示します。

したがって、_untrackedfile_の緑色のUとの混同を理解しています。 また、緑のUが緑のAと混ざり合って目が痛くなることも予想しています。

Atomは、追跡されていない新しいファイルとステージングされた新しいファイルの両方を緑色で色付けし、Xcodeは、新しいファイルである限り、追加されたファイルをAとしてマークします。 どちらも少しも気になりませんでした（ただし、緑色のUは気になります）。

だから私はすべて、追跡されていない_および_ステージングされた新しいファイルに緑色のAを使用することにします。

「U」対「A」対「？」を続けましょう https://github.com/Microsoft/vscode/issues/36912での議論

同意します。 今日のインターフェースで使用されている文字を継続する方が良いと思います。 「U」も好きではありませんが、これはこの機能リクエストの範囲外だと思います。 これが変更された場合、プログラム全体で変更されるはずです。

OK、これは巨大なスレッドであり、私はそれをざっと読む時間しかないので、ここで言います：これを無効にする設定があることを願っています。 私はすべてのファイル名を同じ色で表示することを好みます。それらのステータスを確認する必要がある場合は、 git statusます。 :-)

この製品は放棄されていますか？ と思われる。

現在、 list.activeSelectionForegroundはgitステータスのスタイルよりも優先されているようです。そのため、選択したファイルではgitステータスの色を確認できません。 この情報は、現在選択されているファイルであっても、役立つと思います。 explorer.decorations.colorsがtrueの場合、gitステータスのスタイル設定が優先される可能性はありますか？
この動作は、インサイダー1.188dfa696で観察されました。

現在、list.activeSelectionForegroundはgitステータスのスタイルよりも優先されているようです。そのため、選択したファイルにgitステータスの色を表示することはできません。

確かに、ここでは最新のインサイダーについても同じです（更新されたばかりです）。 プロジェクトツリーでファイル名をクリックすると、ファイルエントリの色が変更されます（たとえば、黄色/変更済みからニュートラルに）。 また、これはかなり紛らわしい動作だと思います。 ユーザーがファイルをクリックしても、ファイルの色は変わらないはずです。

ところで、開いているファイルのリストと同じ問題ですが、そこでファイルをクリックすると、gitステータスの色がニュートラルな選択の色に置き換えられます。

ところで、開いているファイルのリストと同じ問題ですが、そこでファイルをクリックすると、gitステータスの色がニュートラルな選択の色に置き換えられます。

まあ、それは意図的に行われたものです。なぜなら、選択前景の色が装飾の色と衝突することがよくあるからです。 git.untrackedSelectedForegroundやgit.untrackedFocusedForegroundような色を追加することは、私たちにとってあまり魅力的ではなかったようです。 そこで我々は、項目が選択されたときに選択色が勝つせて、フォーカスを持っています。

Atomには問題がないようです。

新しい設定は必要ありません...選択したアイテムの背景色が干渉する場合に対応するために、テーマが更新されます。 そうしないと、コミュニティはそれらのテーマを使用しないことを決定します。

私はチェックしていませんが、「バッジ」（つまり、U、M）がまだsvgファイルではないことを願っています。 スタイルや色を付けることができる生のテキストである必要があります。

正直なところ、VSCodeは、不格好な構成設定ではなく、これらのスタイルシートを使用する必要がありました。 それはかなり単純なプロセスを過度に複雑にしました。

@WadeShuler選択とフォーカスがあり、スクリーンショットにエディターカーソルが表示されているため、アイテムは選択されているだけで、フォーカスされていないと思います。 実際、選択したものとフォーカスしたものでAtomに違いは見られません。 これがVSCodeでの方法です

選択されているが焦点が合っていない

選択され、焦点を合わせた

@jriekenダブルチェックしましたが、Atomで、選択したものとフォーカスしたもので同じ結果が得られます。 左側のファイルエクスプローラーウィンドウのyellowフォントの色が失われることはありません。 2番目のスクリーンショットでは、 red色がtest.fooから失われています。これが問題です。

デフォルトの暗いAtomテーマと明るいAtomテーマ、および他の約3つのテーマを試しました。 私のデフォルト（私のSSに見られるように）はSeti（UIとテーマの両方）です。 何をしても、Atomにファイルエクスプローラーからyellowカラーをドロップさせることができません。 Atomバージョン1.21.2。

選択済み

選択され、焦点を合わせた

すぐに使用できるVSCodeは、選択された状態やフォーカスされた状態に関係なく、gitステータスの色を保持する必要があります。

あなたの問題がテーマであるならば、それはあなたの問題ではありません。 これは、テーマ開発者が更新して対応する責任です。

補足：最新のインサイダーをチェックアウトしたり、コードを表示したりしていませんが、 git ignoredファイルはフォントの色ではなくopacityを使用する必要があるため、常にx色に関係なく、通常のファイルよりも暗い。

@WadeShulerは、テーママネージャーがビジネスをどのように処理するかについてのフィードバックに感謝します。 VSCodeチームがそれを行うのに役立つAPIをどのように提供しますか？ それらの怠惰な開発者！

@fernandofleuryテーママネージャーにそれを管理するためのAPIを提供しないことについては誰も何も言いませんでした。 私の投稿はそのようなことは何も言っていません。 したがって、あなたの卑劣なコメントは、単に無効であり、正当化されません。

@jriekenは言った：

まあ、それは意図的に行われたものです。なぜなら、選択前景の色が装飾の色と衝突することがよくあるからです。

私は言った：

あなたの問題がテーマであるならば、それはあなたの問題ではありません。 これは、テーマ開発者が更新して対応する責任です。

問題は、ファイル/フォルダーツリーアイテムの前景色（実際には背景色）と、さまざまなgitステータスのフォントの色の選択（通常、選択、フォーカス）の間の競合です。

これは、テーマ開発者の責任です。 競合しないように、ツリー内のアイテムの前景色とさまざまなgitステータスのフォント色の両方を選択する必要があります。

例：テーマ開発者はThemeXを使用しており、エクスプローラーファイルツリー内のアイテムのフォントの色はyellowです。 彼のデフォルトのフォントの色は、デフォルトのyellow gitステータスの色と競合します。 どのファイルが変更されたかを知ることはできなくなります。 したがって、これはテーマ開発者の責任になります。 -エクスプローラーファイルツリー内の選択された/選択されたフォーカスのあるアイテムの背景色とgitステータスのフォントの色についても同じです。

これは今延期されていますか？

@IljaDaderko次の安定バージョンの次のリリースノートv1.18に表示されるので、そうは思いません。 問題はもっとあるかもしれません、これは閉じられるのでしょうか、それともまだやるべきことがまだあるのでしょうか？

@IljaDaderko VSCode v1.18はすでに

無視されたファイルの色はv1.18アップデートの一部であると想定されていますか？ ドキュメントには、無視されたファイルに色を付けるためにgitDecoration.ignoredResourceForegroundを使用できると書かれていますが、これまでのところ、それが何かに影響を与えることはわかりません。 ただし、変更された/追跡されていないカラーリングはうまく機能します。 これは安定した1.18.0のウィンドウにあります。

ここでも同じです（無視された色について）。 このGitの実装全体が始まって以来、私も働いていません。 インサイダーの使用。
gitDecoration.ignoredResourceForegroundが行うことは、無視されたファイルを色付けから無視することだけです:)

それは私のために働いていて、それは壮観に見えます。

最後にここにあります🥇

@arxpoeticaこれは私が得るものです：

一部の人にはどのように機能し、他の人には機能しないのでしょうか。わかりません。 gitDecoration.ignoredResourceForeground設定するの
それが機能しないのは私だけですか？ 本当に誰もいないのですか？ :)ああ、そして@Shurelia
他の誰か（私たち、ユーザー）は、それが機能すると言う前に、無視された色の設定を実際にテストしましたか？

OS：Windows 10 PRO（1709）
VSCode：1.19.0-インサイダー（以前に更新されたばかり）
仕事用のラップトップと自宅のデスクトップでも同じです。

インサイダーですか？ どうすれば使用できますか？

みなさん、おめでとうございます！

@ nkkollaw😎インサイダーと安定版の両方で（1.18）

@MrCroftここでgit-ignoreの問題について話し合ってください： https ：

この機能は最新の安定版ビルドで出荷されているので、この問題を閉じてロックします。 トピックディスカッションとバグレポートのために新しい問題を作成してください。 この領域に関する問題は、 file-decorationsラベルでタグ付けされています。

皆さん、この機能をそれが何であるかを作った素晴らしいそして継続的なフィードバックに感謝します！

私の前のコメントを要約して繰り返すために。

いくつかのこと

• デフォルトでは、色とバッグの組み合わせがあります。
  
  
  
  • 次のアイコンを有効/無効にします： "explorer.decorations.badges": true|false
  
  
  • "explorer.decorations.colors": true|false色を有効/無効にする
  
  
• 色は、ファイルツリー、開いているエディターセクション、およびSCMビューレットに表示されます
• そもそも3色あります。 workbench.colorCustomizations設定でカスタマイズできます。 色はgitDecoration.modifiedResourceForeground 、
  gitDecoration.deletedResourceForeground 、
  gitDecoration.untrackedResourceForeground 、
  gitDecoration.ignoredResourceForeground 、および
  gitDecoration.conflictingResourceForeground