• 1

Wäre cool, wenn dies in irgendeiner Weise als Erweiterung freigelegt würde. Ich mache mir Sorgen, dass der Baum in einigen Fällen etwas mit Farbe verschmutzt sein kann und wie ein Weihnachtsbaum aussieht. Oder wenn nicht, haben Sie zumindest die Möglichkeit, es ein- und auszuschalten.

Ja, ich stimme zu. Ich habe ein separates Problem erstellt, um dies in der Erweiterungs-API verfügbar zu machen (siehe Nr. 1394).

+1

Würde das auch lieben. Die Registerkarte Git ist sehr praktisch, aber dies hat einen anderen Zweck - Farben wie in Atom zu haben, wäre sehr komplementär, um auf einen Blick zu sehen, was sich wo geändert hat (wobei sich die Farbe automatisch bis zum obersten Verzeichnis ausbreitet). Das ist wahrscheinlich das Feature, das ich von Atom am meisten vermisse.

Normalerweise haben Sie keine 10 oder 100 geänderten Dateien, die nicht festgeschrieben sind, daher ist es unwahrscheinlich, dass sie wie ein Weihnachtsbaum aussieht :)

Es sieht also so aus, als ob die PR dafür geschlossen wurde. @bpasero @joaomoreno - irgendwelche Updates zum Stand dieser Arbeit?

Überprüfen Sie dies https://github.com/Microsoft/vscode/pull/8462

Keine Aktualisierungen...

Vielen Dank für Ihr Interesse an diesem Thema! Es ist derzeit dem Backlog zugeordnet. Jeden Monat wählen wir Elemente aus dem Backlog aus, um für die aktuelle Iteration zu planen. Weitere Informationen finden Sie unter https://github.com/Microsoft/vscode/wiki/Issue-Tracking#planning .

Da wir ein kleines Entwicklerteam sind, gibt es nur eine begrenzte Anzahl von Funktionsanfragen und Problemen, an denen wir für einen Meilenstein arbeiten können. Trotzdem freuen wir uns immer über Pull Requests und nehmen diese gerne an, wenn sie unseren Qualitätsansprüchen genügen.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Bitte hör auf, +1 schreiben. Es schickt jedem in der Ausgabe eine E-Mail. Verwenden Sie die Emoji-Reaktionen beim ersten Kommentar.

+1

Hallo, hast du Neuigkeiten zu diesem Feature-Request? Ich habe heute angefangen, den vscode zu verwenden und ich liebe ihn schon, aber ich vermisse wirklich die Farben, die die Änderungen anzeigen
Herzlichen Glückwunsch zu deiner Arbeit

+1

Beachten Sie bei der Implementierung bitte 206

Ich füge ein paar Screenshots hinzu, um zu helfen:

Atom-Standard:

VSCode-Standard:

+1

+1

Dies wäre sehr nützlich.

Es besteht bereits die Möglichkeit, die Art und Weise, wie Dateien und Symbole im Dateibaum aufgelistet werden, zu ändern.
Diese Erweiterung macht's
https://github.com/robertohuertasm/vscode-icons.

Es färbt die Dateinamen jedoch nicht ein

+1

+1

gibt es Änderungen? Diese Funktion hindert mich daran, von Atom zu wechseln. :(

Ich bin gerade von Atom weggezogen, da sich die Leistung in VSC viel besser anfühlt. Dies ist jedoch eine Luxusfunktion, die ich in VSC vermisse.

+1

Ich denke, es wäre schön, dies als integrierte Einstellung (zB git.colorExplorer ) anstelle einer Erweiterung zu haben.

@arkon gibt es eine solche Erweiterung? Ich konnte keine finden.

Höchstwahrscheinlich hat der Datei-Explorer keine API, um ihn entsprechend zu ändern
git Änderungen. Eine Verlängerung wäre für mich in Ordnung.

Am Freitag, 3. Februar 2017, 07:52 Uhr schrieb Rahul [email protected] :

@arkon https://github.com/arkon gibt es eine solche Erweiterung? ich konnte nicht
finde irgendein.

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/Microsoft/vscode/issues/178#issuecomment-277177373 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AEQJ1eoLm7Sp59a2hE0tIFQnb0Q5cJnSks5rYs6tgaJpZM4GlYyH
.

@rahulnever2far Nein, es war nur ein Vorschlag, da zuvor vorgeschlagen wurde, dass es als Erweiterungs-API

Kürzlich beschlossen, auf VSCode umzusteigen, und ich vermisse diese Funktion wirklich

Bitte hinzufügen. Erhöht die Produktivität beim Versuch, von Atom zu springen.

@KozhokarAlex @bhudgens und andere: Klicken Sie im ersten Beitrag auf das Symbol "Daumen hoch", um den Entwicklern zu zeigen, dass Sie diese Funktion anfordern. Sie sortieren Probleme mit Daumen nach oben, um festzustellen, welche Funktionsanfragen am beliebtesten sind.

Wie Sie an dieser Art von Problemsortierung sehen können, ist dieses Problem derzeit die am dritthäufigsten nachgefragte Funktion.

Daumen hoch. Kam vor kurzem von Atom..hoffe, es bald in VSCode zu sehen!

Ah danke @joaomoreno!

Bitte fügen Sie QuickOpen auch den gleichen Farb- / Qit-Status hinzu, nicht nur FileExplorer.
Auf diese Weise können geöffnete Dateien anhand bereits geänderter Dateien visuell gefiltert werden.

was ist damit los? Warum werden die Betreuer @joaomoreno PR nicht zusammenführen? Gibt es ein Plugin, das wir jetzt verwenden können? das ist einfach albern

@SOSANA Sie sind sich nicht sicher, was Sie mit PR meinen, welche PR meinen Sie?

2824 öffnet die Tür, um dieses Problem zu beheben, also haben Sie noch etwas Geduld.

@SOSANA das ist ein Thema, keine PR

+1 Diese Funktion wäre erstaunlich für die Produktivität

+1

@publiclass1 @hevans90 , ... (fügen Sie alle anderen Personen ein, die mit +1 kommentiert haben) ..., BITTE posten Sie keine Kommentare darüber, wie sehr Sie diese Funktion wünschen. Dafür hat GitHub die Emoji-Reaktionen hinzugefügt. Daumen hoch für den Originalkommentar. Auf diese Weise kann ich wieder E-Mail-Benachrichtigungen verwenden, für die sie gedacht waren (halten Sie sich über den Fortschritt dieses Problems auf dem Laufenden und nicht wer auf der Welt dies auch möchte). Sorry an alle, dass ihr euch auch spammt. Ich hoffe aufrichtig, dass mehr Leute lernen, +1 -ing Probleme zu stoppen.

+1

Ich verwende PhpStorm, würde aber lieber VS Code für alles verwenden. Ich verwende derzeit so viele VS Code-Fenster wie möglich. Können Sie dieses Farbsystem bitte irgendwann als Option haben, da ich die PhpStorm-Farben bevorzuge / kenne. Als Referenz:

Schwarz - Aktuell - Datei ist unverändert.
Grau – Gelöscht – Die Datei ist zum Löschen aus dem Repository geplant.
Blau - Geändert - Datei hat sich seit der letzten Synchronisierung geändert.
Grün – Hinzugefügt – Die Datei soll dem Repository hinzugefügt werden.
Braun - Unbekannt - Die Datei ist lokal vorhanden, befindet sich jedoch nicht im Repository und ist nicht zum Hinzufügen geplant.

usw. über https://www.jetbrains.com/help/phpstorm/2016.3/file-status-highlights.html . Ihr rockt, danke.

und

• Dateien, die mit Konflikten zusammengeführt wurden, werden rot dargestellt,

Es ist sehr praktisch, Konflikte von anderen zu unterscheiden

+1 Zwischen den Ansichten von Git <> Explorer hin und her wechseln zu müssen, ist sehr unproduktiv.

Im Idealfall wäre es auch möglich, das Changeset als Gruppe oben zu sehen, in der wir offene Dateien haben, sowie einen verschachtelten Änderungsbaum, der durch Farbe visualisiert wird (wie von @abdonrd oben gezeigt).

Kommt, Leute, hört einfach mit dem +1 auf.

Bitte Daumen hoch auf den ersten Beitrag.

Ich habe einen interessanten Anwendungsfall und ein Argument, um eine generische API zu erstellen, die es dem Plugin ermöglicht, einzelne Dateien und Ordner einzufärben:

Datei- / Ordneralterung ähnlich wie beim Trello-Aging-Powerup - Ich möchte, dass die Dateien und Ordner, die lange Zeit nicht berührt wurden (gemessen an der Git-Historie), ausgeblendet werden, damit das "Arbeitsset" deutlicher und leichter zu finden.

Warum? Links, die auf Repo verweisen).

Wenn es einen API-Endpunkt zum Einfärben von Baumelementen gäbe, könnte ich ein Plugin schreiben, das das Git-Protokoll liest und jede Datei/jeden Ordner nach bestimmten Regeln einfärbt.

Was ist also damit, gibt es nicht immer noch eine API, die es ermöglicht, eine Erweiterung dafür zu erstellen, oder wird dies als integriertes Feature implementiert?

Gibt es hierzu Neuigkeiten?

+1

+1

+1

Könnt ihr bitte aufhören +1 zu senden und unsere E-Mail-Postfächer zu spammen???

Es erfüllt überhaupt keinen Zweck.

+1 bis kein Spam xD

protip: Nachrichten von github herausfiltern, bei denen der Körper gleich/übereinstimmt/lolwuts "+1" ist

Du kannst diese Leute nicht aufhalten.

@jmbelloteau wie @fredrikaverpil bereits in den Kommentaren sagte, werden VSCode-Probleme nach der Anzahl der Daumen hoch bis zum ursprünglichen Kommentar sortiert. „+1“ zu kommentieren, anstatt dem ersten Kommentar eine Reaktion hinzuzufügen, ist in der Tat Spamming, da es nicht der richtige Weg ist, Feedback zu geben und nur nutzlose E-Mails an alle gesendet werden. Und im Gegensatz zum Hinzufügen einer Reaktion wird diese nicht einmal berücksichtigt.

+1

Ich bin das in Webstorm auch so gewohnt :D. Aber wie ich sehe, wird dies wahrscheinlich früher als später entwickelt. Hier ist ein Screenshot von Webstorm zur Inspiration (nach @abdonrd):

Ah, auch ungetrackte Dateien werden rot dargestellt!

+1

Habe heute zum ersten Mal VS-Code ausprobiert (von Atom) und eine der ersten Erweiterungen, nach denen ich gesucht habe, war die Hervorhebung von "git status" in der Explorer-Ansicht. Die Registerkarte "Quellcodeverwaltung" an sich ist sehr schön, aber wenn Ordner/Dateien hervorgehoben sind, kann ich schnell zu der Komponente navigieren, an der ich arbeite, ohne meinen Verzeichnisbaum immer erweitert lassen zu müssen (sehr nützlich für FE-Codebasen, die dazu neigen tiefer verschachtelte Strukturen haben).

Ideal wäre es, wenn die Farben individuell angepasst werden können.

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

+1

Ich habe lange nach einer guten App gesucht, die mich daran erinnert, Wasser zu trinken.
Dann habe ich gemerkt, dass ich diesen Thread abonniert habe.
Behaltet die +1, die kommen, Jungs, sie sind nicht mehr nutzlos 🚰

@mmazarolo
Warum brauchen Sie eine Erinnerung, um Wasser zu trinken? Reicht es nicht, bei Durst zu trinken?

Wie auch immer, bitte hör auf +1 zu geben. Ich bin sicher, die Entwickler sind sich dessen bereits bewusst und werden Updates veröffentlichen, sobald sie kommen.

@pohmelie das ist eine gültige Alternative, danke!

+1

wtf ist mit diesen +1 Leuten falsch?

Tolle Idee, @davidhu2000! Es wäre schön, auch Hex-Farben wie git.ignoredFileColor: '#333333' zu unterstützen.

Es gibt eine schöne Liste der Typen und Farben, die JetBrains hier verwendet: https://www.jetbrains.com/help/idea/2017.1/file-status-highlights.html (Sie können den Farbnamen überprüfen, um das Hex zu erhalten).

+1 zur Sensibilisierung dafür, wie sehr diese Funktion gewünscht wird

Der einzige Grund, warum ich VS Code nicht verwende. Schade :(

Weiß jemand, wo in der Codebasis man anfangen könnte, dies zu implementieren? Ich möchte es in Angriff nehmen.

@admosity Jemand hat letztes Jahr bereits einen Pull-Request eingereicht, der abgelehnt wurde: https://github.com/Microsoft/vscode/pull/8462 .

2824 wurde oben als Blocker erwähnt, der vor einiger Zeit zusammengeführt wurde. Ich würde mir die Änderungen dort ansehen, um sicherzustellen, dass sie so implementiert werden, wie das VS-Team es will.

@AndreasGassmann super ! Ich schau mal vorbei.

Die letzte wichtige Funktion verhindert, dass ich zu vs-Code wechseln kann

Wenn diese Funktion integriert ist, werde ich zu vscode wechseln

Ich habe dieses Thema abonniert, weil ich wissen möchte, wann Fortschritte gemacht werden.
Jeder weiß, wie gewollt dieses Feature ist und ist derzeit das

Wenn Sie diese Funktion wirklich, wirklich wollen, stimmen Sie einfach dem ersten Kommentar zu und vermeiden Sie das Hinzufügen von wiederholten Kommentaren .

Für Leute, die der Meinung sind, dass diese Funktion notwendig ist, um zu VS Code zu wechseln. Ich kann sagen, dass es das erste Feature war, das ich beim Wechsel von Atom vermisst habe, aber IMO ist dies ein kleiner Preis für diese großartige IDE.
Außerdem musste ich letzte Woche etwas in Atom arbeiten und habe die Git-Ansicht von VS Code wirklich vermisst.

@waderyan Dies ist ein Dealbreaker, der sich vom Atom wegbewegt.

Ja bitte!

+1

+1

+1

Ich habe einen sehr hässlichen Hack gemacht, der diese Funktion implementiert, indem ich workbench.main.js modifiziert und das CSS basierend auf der Ausgabe von git status eingefügt habe. Wenn es Ihnen nichts ausmacht, durch interne VS Code-Dateien zu wühlen und Ihren VS-Code alle 5 Sekunden git status ausführen zu lassen, werfen Sie einen Blick darauf.

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

Update 28.6.2017: Es wurde ein Fehler behoben, bei dem das Plugin beim erneuten Öffnen des Projekts nicht geladen wurde.
Update 30.6.2017: Hervorhebung der übergeordneten Verzeichnisse geänderter Dateien hinzugefügt (wie Atom es tut).
Update 1.7.2017: Der Dateiabgleich erfolgt jetzt unter Verwendung des vollständigen Datei- oder Verzeichnispfads. Vor dieser Änderung wurde das Verzeichnis hervorgehoben, wenn es denselben Namen wie ein anderes geändertes Verzeichnis hatte.

Hallo,
Ich kann nicht herausfinden, ob diese Funktion implementiert ist oder noch nicht?
Ich habe keine Einstellungen oder Erweiterungen gefunden und da dies vor fast zwei Jahren geöffnet wurde, bin ich verwirrt.

@sanjibukai Das Problem ist noch offen, daher wurde es noch nicht implementiert. Sie können jedoch den Hack verwenden, den @karabaja4 im Kommentar über

Ich bin neu hier, aber braucht es wirklich fast zwei Jahre, um dieses offensichtliche Feature hinzuzufügen?
Überraschenderweise habe ich bis vor kurzem noch nie von vscode gehört, aber als ich davon hörte, wurde das Hauptmerkmal, das befürwortet wurde, genau, wie gut vscode git integriert. Und in der Tat ist es gut.
Schade, dass diese Funktion noch fehlt..
Trotzdem weiterhin gute Arbeit vscode Team

Ohne diese Funktion kann ich mich nicht konzentrieren. Jedes Mal muss ich mir merken, welche Datei ich bearbeite.

+1

@karabaja4 warum machst du nicht eine PR mit deinem Hack und

@saada Ich würde das tun, wenn ich dachte, dass dieser Code in VS Code integriert werden könnte. Das Ausführen eines git status Hintergrundprozesses ist sicherlich kein vernünftiger Weg, um diese Funktion zu implementieren. Jeder geeignete Code, der dies implementiert, muss von Grund auf neu geschrieben und im VS Code-Quellframework korrekt implementiert werden. Das ist viel Arbeit und leider habe ich im Moment nicht genügend Zeit zur Verfügung. Es tut uns leid :(

Anhäufen wird nicht helfen, wenn ihre angegebene Metrik bereits die Anzahl der +1 ist, die der ursprüngliche Beitrag erhält, nicht in Antworten. Wenn man bedenkt, dass dies ein Tool für Entwickler ist, bin ich auch etwas erstaunt, wie viele Berechtigungen es gibt und wie nicht der Open-Source-Prozess hier vor sich geht. Die Feature-Anfrage ist hier als offenes Thema. Sie können dem Beitrag +1 geben und es entweder selbst tun (vermutlich in Zusammenarbeit mit den Betreuern, um sicherzustellen, dass es nicht umsonst ist) und eine Zusammenführung anfordern oder es einfach dabei belassen. Wenn es eine wichtige Funktion für Sie ist, verwenden Sie Atom. Während ich dies schreibe, gibt es über 4000 offene Fragen. Sie müssen Geduld üben.

(Oder verwenden Sie in der Zwischenzeit den

+1
Tun Sie dies, weil Sie einfach zuhören, um über Devchat zu sprechen, und Probleme mit mehr Kommentaren werden mehr Aufmerksamkeit erhalten

@karabaja4 tolle Arbeit. Ein anderer Ansatz: Wie wäre es, wenn Sie git status bei init ausführen und dann aktualisieren, wenn das Ereignis onFileSave ausgelöst wird? wäre das effizienter?

Vielleicht könnten wir die Art und Weise konfigurieren, wie wir den Git-Status aktualisieren.

+1 das wäre sehr hilfreich wenn es hinzugefügt wird

@Kaijun Ich bin mir nicht sicher, wie ich das implementieren würde. Woher würde das Ereignis onFileSave kommen?

Wenn es vom Code beim Speichern des Dokuments stammt (vorausgesetzt, ich weiß, wie man es anhängt), werden die außerhalb des Codes geänderten Dateien ignoriert, ebenso wie Änderungen wie das Verschieben und Kopieren von Dateien.

Wenn es von einer Ordnerüberwachungslogik stammt, die im Lösungsbaum implementiert ist, müsste dies rekursiv für den gesamten Baum erfolgen. Ich bin mir nicht sicher, ob es sich leistungsmäßig lohnt.

@karabaja4 Ich denke, Code erkennt auch äußere Änderungen. Das Einhaken in ein solches "Ereignis" mit möglicherweise einem Debounce-System, damit mehrere Dateiänderungen im gleichen Intervall nicht zu viele Git-Statusprüfungen auslösen. Das könnte funktionieren!. Vielleicht kann sich jemand, der mit dem fs-Stück vertraut ist, einschalten?

Das sollte wirklich nicht im Rückstand sein. Es ist sehr wertvoll, diese scheinbar kleine Funktion hinzuzufügen. Das Glück der Entwickler geht weiter. Es ist entmutigend zu sehen, dass dieses Problem Tausende von +1 hat und seit 2015 nicht mehr berücksichtigt wird.

@kamok stimmt das! Obwohl Atom langsam ist, hatte ich eine andere Option ... Ich ging zurück zu WebStorm, das bei der Integration in Git und anderen Funktionen, für die Sie Erweiterungen auf vscode installieren müssen, ungeschlagen ist und es immer noch so schnell ist und scheinen in Bezug auf die Geschwindigkeit eher ein leichter Editor als eine IDE zu sein. Diese Funktion allein (Git-Status im Datei-Explorer) würde immer noch nicht ausreichen, um vscode-Benutzer zu halten. Das wäre nur ein Tropfen auf den heißen Stein. Es ist die Funktion, die ich am wenigsten vermisse, da sie von WebStorm kommt.
Ich schlage vor, dass das vscode-Team sich ansieht, wie die Jungs von JetBrains es machen.
Es tut mir leid, aber ich habe es versucht ... Ich habe jetzt monatelang mit vscode gekämpft, auf Update auf Update gewartet, aber ich habe immer wieder vscode geschlossen und das Projekt in WebStorm erneut geöffnet für: Git-Status im Explorer Baum, Stashes, Ordner-/Baumansicht für lokale Änderungen, Vergleich von Zweigen, Rechtsklick > Mit Zwischenablage vergleichen ... Und das ist mir gerade eingefallen. Die Vscode-Git-Integration hat noch einen langen Weg vor sich, wenn sie Entwicklern wirklich helfen wollen.

_Gesendet von meinem Samsung SM-G950F mit FastHub _

@MrCroft Ich schlage vor, dass Sie sich direkt an das Team wenden, wenn Sie sich so Sorgen über die Arbeitsmethodik machen. Andernfalls geben Sie dem Problem mit einem Daumen nach oben +1 und wechseln den Editor, wenn es Sie so sehr stört.

@cucumbur habe ich bereits gemacht (von vscode gewechselt). Ich drücke nur meine Trauer aus, weil ich wirklich mochte, wie sich vscode anfühlte. Ich hätte es geliebt, wenn es eine gute Git-Integration hätte, damit ich es weiter verwenden könnte. Ich bin sicher, vielen geht es ähnlich.
Ich werde es noch im Auge behalten. Vielleicht, wer weiß, in einer "nicht sehr fernen Zukunft" würde es passieren... Abgesehen von vscode bin ich eigentlich ein riesiger Microsoft-Fan... Software und Hardware bauen 9 von 10 Mal sehr hochwertige Sachen . Ich hoffe nur, dass vscode einer der 9 wird.

_Gesendet von meinem Samsung SM-G950F mit FastHub _

@kamok Jedes neue Problem geht in den Backlog und bleibt dort, bis es angegangen wird. Ich glaube nicht, dass diese Funktion außer Acht gelassen wird. es erfordert nur mehr Änderungen, als Sie denken. Soweit ich weiß, möchten sie dies zu einem Teil der Erweiterungs-API machen, und derzeit fehlen dem Dateibaum viele Funktionen, um dies zu ermöglichen.

Wenn Sie die Probleme nach Daumen nach oben sortieren, sehen Sie, dass dieses Problem das zweitbeliebteste ist, das erste wird bearbeitet und ist fast fertig. Ich bin mir ziemlich sicher, dass sie anfangen werden, daran zu arbeiten, sobald das andere fertig ist.

Ein gelegentliches Update zu diesem Thread wäre aber toll.

Wenn Sie von Atom gewechselt haben, aber in einem großen Projekt keine aktualisierten Dateien hervorgehoben haben, ist es schwierig, damit zu arbeiten.
Zurück zu Atom wechseln, bis diese Funktion verfügbar ist

Vielleicht erwähnenswert, dass eine alternative / Zwischenlösung, die für mich funktionieren würde ... darin besteht, die Baumstruktur in der Ansicht "Open Editors" duplizieren zu lassen. Normalerweise zeigt die Ansicht "aktualisierte" Dateien an, aber es ist nur ein Dump von Dateinamen, mit denen es schwieriger zu arbeiten ist, als wenn klar wäre, wo im Projekt diese Dateien zu finden sind.

Irgendwelche Updates dazu?

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

Ich bin masochistisch mein eigener Kommentar.

Ich versuche es immer wieder mit VSCode, aber da diese Funktion fehlt, hindert sie mich daran, zu wechseln. Ich habe nicht gemerkt, wie sehr ich mich auf diese Funktion in Atom verlasse, bis ich versuchte, zu wechseln.

Ich warte nur darauf, dass dies von Atom auf VS-Code umgestellt wird, und hoffe, dass es bald implementiert wird.

+1

zwei Jahre sind vergangen。。。

und überraschenderweise hat Ihr Kommentar daran nichts geändert. Diejenigen von uns, die sich für die Entwicklung und mögliche Beiträge interessieren, abonnieren diese Thementhreads, Ihr Kommentar hat nichts geholfen und eine nutzlose E-Mail an 99 Personen gesendet

Hey, du bekommst keine Ergebnisse, es sei denn, du versuchst es, oder?

Ich habe es anfangs sehr vermisst, und obwohl es sehr praktisch wäre, es zu haben, ist der 'Diff Explorer' (drittes Symbol im vertikalen Menü) wirklich mächtig und sehr nützlich

+1
Wäre super wenn das wooow implementiert würde...!

Ich habe eine Schluckaufgabe geschrieben, die die Installation des Hacks vereinfachen soll (nur 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 Noch nicht auf allen Plattformen getestet, würde mich freuen, wenn es jemand unter OSX ausprobieren würde.

@karabaja4 Es scheint nicht so, als ob Ihr "Hack" so kompliziert in vscode selbst zu implementieren ist. Da es so aussieht, als würden die vscode-Entwickler dieses Problem nicht so schnell beheben, könnten Sie vielleicht einen Pull-Request erstellen?

@karabaja4 Danke dafür! Arbeitet für mich auf macOS Sierra, VSCode 1.15.1.

@karabaja4 Danke! Arbeiten hier an Fedora 26, VSCode 1.15.0. Das allein machte den Umstieg von Atom sooo viel bequemer.

@karabaja4 +1 Danke!! Arbeiten für mich unter Ubuntu 14.04 64, VSCode 1.15.1 (manuelle Installation)

+1

@karabaja4 +1 Das ist großartig.

+1

@matti plus eins

_Gesendet von meinem HTC MSM8996 für arm64 mit FastHub _

@ibrokemypie minus zwei

Gesendet von meinem HTC MKB826262 für arm32 mit Lolbug

Gibt es Neuigkeiten zu dieser Funktion?

+1

+1

+1

@karabaja4 DANKE Mann =D <3

+1

Wow, das hätte schon vor zwei Jahren umgesetzt werden sollen

@eosrei +1

+1

+1
Stellen wir uns der Realität; Ich liebe VSCode, aber der Git-Tab ist wirklich scheiße

@karabaja4 Hi, 1.16 ist gerade

BEARBEITEN: Funktioniert mit 1.16, nur nicht bei Verwendung von Multi-Root-Workspaces.

@ karabaja4

@karabaja4 hat mir gerade den Tag

+1

+1

Ein +1 Kommentar sollte ein automatischer Bann von GitHub-Problemen sein...

Wäre schöner, wenn GitHub nur +1-Beiträge parsen und automatisch durch eine Emoji-Reaktion mit dem Daumen nach oben auf den ursprünglichen Beitrag ersetzen würde.

@karabaja4 dein Hack läuft auf OSX 10.12.6 - genial! Dankeschön.

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

Das einzige, was ich jetzt beim Booten bekomme, ist eine Warnmeldung . Zum Glück ist es nur eine Warnung.

VSCode-Version 1.16.0

+1

Gibt es einen Grund, warum dies noch nicht implementiert ist oder gibt es einen Zeitplan, wann diese Funktion hinzugefügt wird?

Gestern bin ich für eine Stunde zu Atom zurückgekehrt, um das neueste ide-Update zu verwenden, und ich dachte, mein Leben mit farbigen Dateien in der Dateibaumansicht ist so einfach.

Edit: Habe gerade einen Workaround gefunden. Das Hinzufügen einer Zeile zu einer der vs-Code-Dateien (< 1 Minute Aufwand) funktioniert wie ein Zauber! https://github.com/karabaja4/vscode-explorer-git-status

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

Hast du jemals gesehen, dass du Emoji-Reaktionen verwenden kannst, anstatt +1 posten?

Jedes Mal, wenn wir Kommentare auf github veröffentlichen, erhalten alle Abonnenten des Themas Benachrichtigungen und einige Benutzer erhalten auch E-Mails. Es ist irgendwie frustriert, eine E-Mail zu lesen, die geschrieben wurde: +1 und Sie können in diesen Kommentaren sehen, dass es viele :-1: gibt.

Die Community freut sich, wenn wir stattdessen alle anfangen, die Reaktionen zu verwenden:
https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments

Ich entschuldige mich für jede Beleidigung dieser Informationen und für die anderen, die diese Benachrichtigung erhalten.

Ich hatte in anderen Threads gelesen, dass Microsoft die Priorität eines Features nach der Anzahl der +1-Kommentare bewertet. Ich entschuldige mich, wenn ich das falsch gemacht habe und in keiner Weise ist, wie ein Feature eingestuft wird. Ich habe meinen Kommentar entfernt. Wie auch immer, was ist mit der aggressiven Einstellung, Bruder? Du hättest mit einem besseren Ton auf

Danke schön.

Hallo @aecorredor , ich entschuldige mich, wenn es unhöflich klang.
Ich bin kein englischer Muttersprachler und vielleicht klang einer meiner übersetzten Ausdrücke schlecht. Bitte helfen Sie mir, die Beschreibung für diesen Kommentar zu verbessern. Soll ich das Wort nervig ersetzen? nutzlos? Vielen Dank.

PS: Ich bin froh, dass Sie die Welt, die ich in meiner E-Mail gelesen habe, bearbeitet haben, denn ich habe vielleicht unhöflich geklungen, aber es war nie meine Absicht, jemanden zu beleidigen.

Update: Ich habe meinen vorherigen Kommentar ersetzt, bitte lass es mich wissen, wenn es besser klingt. Vielen Dank

Hallo @leocaseiro ,

Entschuldigung, dass ich dieses böse Wort überhaupt geschrieben habe. Ich habe es tatsächlich gemerkt
dass eine Sprachbarriere wahrscheinlich die Verwirrung verursachte. Aber
Ja, ich würde diese beiden Wörter durch etwas mehr in der Art ersetzen:
"Bitte, wir versuchen alle, das gesamte Github-Erlebnis für zu verbessern
offene Probleme/Funktionsanfragen, und es wäre schön, wenn die Leute damit anfangen würden
Emoji-Reaktionen anstelle von Kommentaren wie "+1", die nur erstellen
unnötigen Overhead im Thread und lösen E-Mails aus, die nicht wirklich sind
einen sinnvollen Beitrag leisten. Bitte beachten Sie diesen Link, um zu sehen, wie
Emoji-Reaktionen funktionieren: { Link hier }

Prost, und keine harten Gefühle.

Bestens.

Am Montag, 18. September 2017 um 23:44 Uhr, Leo Caseiro [email protected]
schrieb:

Hallo @aecorredor https://github.com/aecorredor , ich entschuldige mich, wenn er ertönt ist
unhöflich.
Ich bin kein englischer Muttersprachler und vielleicht einer meiner übersetzten
Ausdrücke klangen schlecht. Bitte helfen Sie mir, die Beschreibung für zu verbessern
dieser Kommentar. Soll ich das Wort nervig ersetzen? nutzlos? Vielen Dank.

PS: Ich freue mich, dass Sie die Welt, die ich in meiner E-Mail gelesen habe, bearbeitet haben, denn ich darf
haben sich unhöflich angehört, aber es war nie meine Absicht, jemanden zu beleidigen.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/Microsoft/vscode/issues/178#issuecomment-330420547 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AIsVa9fgWXPMFBgkZdHjQHKhUEDJb8Bmks5sjziWgaJpZM4GlYyH
.

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

Verwenden Sie eine Reaktion anstelle eines "+1"-Kommentars.

+1

Ich hatte wirklich gehofft, dass die Anzahl der +1 nach den vorherigen Kommentaren sinken würde, aber dann tauchte plötzlich wieder ein +1 auf 😁 .

Es ist eine Schande, denn Programmierer beschuldigen Benutzer oft, Fehlermeldungen nicht zu lesen, können aber einige Kommentare oder Anweisungen nicht lesen.

Vielleicht lohnt es sich, etwas auf README.md zu setzen, um die Benutzer zu bitten, Reaktionen zu verwenden, anstatt +1 zu kommentieren? Vielleicht ist es auf CONTRIBUTING.md etwas versteckt.

Ich weiß nicht, ich denke, ich werde mich einfach abmelden und auf die Versionshinweise warten, wenn es fertig ist.

Ich habe einen Gist erstellt, der sich darum kümmert. Der Fix von @karabaja4 blendet die ignorierten Dateien/Ordner nicht richtig aus (siehe seine Probleme). Es gibt eine PR von @dseipp , die nie zusammengeführt wurde. Mit seiner PR war immer noch etwas nicht in Ordnung (ich glaube, die inszenierte Unterstützung fehlte?), also habe ich es repariert.

Wenn Sie also möchten, dass dies viel besser funktioniert, sehen Sie sich mein Wesentliches an: https://gist.github.com/WadeShuler/1637073371ad126779076344c34278f3

@ikatyang : Entschuldigung, heißt das, dass diese Funktion im Oktober (2017) eingeführt wird..?

@nkkollaw der Link stammte von diesem Kommentar: https://github.com/Microsoft/vscode/issues/34160#issuecomment -331066864

In dem Kommentar wurde nur darum gebeten, Dinge im Zusammenhang mit diesem Problem hier und nicht im "Iterationsplan" zu diskutieren (und auf Englisch zu diskutieren).

Ah, hab's @tiangolo , danke.

Ich werde versuchen, Atom zu ertragen, bis es eine API gibt, um diese Funktionalität zu implementieren (sorry, ich bin nicht gut genug, um dabei zu helfen).

Ich arbeite daran, das Update innerhalb des Projekts selbst zu machen.
Im Moment habe ich einen Proof of Concept erstellt, der funktioniert, aber ich habe den Tslint nicht bestanden, weil ich die Schichten noch verstehen muss, um alles an die richtige Stelle zu bringen.
Ich werde hier einige Updates veröffentlichen, und wenn mir jemand helfen möchte, werde ich später den Link zu meinem Pull-Request einfügen, damit Sie gerne helfen können.

Geplante Iteration im Oktober 2017!! 👍

Wir haben eine erste Version davon. Alle sind sich sicher, dass dies im Oktober kommen wird.

Noch ein paar Infos:

• Farben werden in Themen definiert, so dass sie nach Ihrem Geschmack angepasst werden können
• Es wird eine Einstellung geben, um dies zu aktivieren/deaktivieren
• Dies gilt nicht ausschließlich für die Versionskontrolle. Wir prüfen auch, Fehler/Warnungen im Datei-Explorer hervorzuheben (siehe #782) und denken darüber nach, dies den Autoren von Erweiterungen zur Verfügung zu stellen.

Offene Fragen:

• Reicht es, nur eine Farbe zu verwenden? Sollte es auch einen Text- und/oder Symbolhinweis geben?
• Welchen Kinderstatus sollte ein Elternteil abholen? Sollte das nach Wichtigkeit gehen? Mit Fehlern und Warnungen ist das einfach, aber was ist noch wichtiger, eine geänderte, eine nicht verfolgte oder eine ignorierte Datei?
• Sollen wir diese Dateidekorationen auch im Bucket "Open Editors" und/oder der Dateiauswahl usw. anzeigen?

Ich werde dieses Thema auf dem Laufenden halten, solange etwas passiert. Verwenden Sie wie immer Emotionen statt "+1"-Kommentare. Danke und viel Spaß beim Codieren!

Persönlich reicht das, was ich auf dem Bild oben sehe, aus. Sieht toll aus und danke!

Es scheint die von .gitignore ignorierten Dateien in Dunkelgrau zu übersehen?

Sie ändern nicht die Farbe (ausgegraut) eines übergeordneten Ordners für nur eine ignorierte Datei darin. Sie grauen es nur aus, wenn der Ordner selbst ignoriert wird. Bitte beachten Sie meinen Kommentar / korrigieren Sie ein paar Kommentare. Es lässt Git die Status ausgeben und erkennt, ob es sich um ein Verzeichnis oder eine Datei handelt. Das einfache Hinzufügen von Klassen zu den Dateien/Ordnern im Dateibaum würde funktionieren ... Wie zum Beispiel „git-status-modified“ oder „git-status-added“. Dann können Themen ihre Magie entfalten.

Es wäre schön, wenn Sie uns Ihre Arbeit machen lassen könnten, damit wir damit spielen und PRs erstellen können. Ehrlich gesagt, wenn es durcheinander geht, werden die Leute wahrscheinlich aufhören, Code zu verwenden, wenn keine praktikable Lösung in angemessener Zeit gefunden werden kann. Viele Leute (einschließlich mir) haben Atom wegen ähnlicher Probleme verlassen.

Ich denke auch, dass bei Fehlern vielleicht ein Punkt vor oder nach dem Dateinamen im Baum verwendet wird. Dies wäre unauffällig, ließe Themes sie stylen und würde die farbliche Hervorhebung von Git nicht stören.

Ja, dies MUSS für Erweiterungsentwickler geöffnet werden! Sollte schon erledigt sein. Warum sollten wir nicht die Kontrolle über den Dateibaum haben wollen, um coole Erweiterungen zu erstellen oder Dinge zu reparieren, die Sie nicht gemacht haben?

Es scheint die von .gitignore ignorierten Dateien in Dunkelgrau zu übersehen?

Sicher, es ist in Arbeit und die Dinge passieren nacheinander. Ignorierte Dateien werden auch im Oktober kommen.

Es wäre schön, wenn Sie uns Ihre Arbeit machen lassen könnten, damit wir damit spielen und PRs erstellen können.

Sicher, es ist alles im joh/feco -Zweig. Es gibt einen neuen Dekorationsservice, der Anbieter für die eigentlichen Daten nutzt. Auf der konsumierenden Seite ist das Dateilabel, das wir zum Rendern von Dateinamen verwenden

Sie ändern nicht die Farbe (ausgegraut) eines übergeordneten Ordners für nur eine ignorierte Datei darin. Sie grauen es nur aus, wenn der Ordner selbst ignoriert wird. Bitte beachten Sie meinen Kommentar / korrigieren Sie ein paar Kommentare.

Ich denke, "ignorierte Dateien und ihre Kinder (falls vorhanden) sind ausgegraut" ist ziemlich klar.

@nkkollaw Wovon ?!

In @jrieken sagte:

“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?“

Er deutete auf eine ignorierte Datei hin, die möglicherweise den Status der übergeordneten Ordner beeinflusst, was nicht der Fall sein sollte!

Ihre passiv-aggressive Nachricht verstopft diesen Thread nur mit nicht hilfreichen Nachrichten ...

@WadeShuler : Ich habe keine Ahnung, wovon _du_ redest.

Ich habe gerade darauf hingewiesen, dass ignorierte Dateien und ihre Kinder ausgegraut werden sollten, und das ist ziemlich klar, dass diese Definition nicht verlangt, dass Eltern von ignorierten Dateien ausgegraut werden.

Wie für:

Ihre passiv-aggressive Nachricht verstopft diesen Thread nur mit nicht hilfreichen Nachrichten ...

Ich habe keine Ahnung, wie passiv-aggressiv meine Nachricht war – ich schätze, Sie wissen nicht, was sie bedeutet –, aber Sie sind diejenige, die diesen Thread verstopft, da Sie der einzige sind, der nach meiner Nachricht einen Kommentar abgegeben hat.

Seltsam.

wow.. gute idee! ich mag das!

Ich möchte den xcode-ähnlichen Texthinweis mit einem einzigen Zeichen in einer rechten Spalte haben. Macht die Dateien einfach visuell zu filtern/zu verfolgen.

@nkkollaw Ich sagte:

Sie ändern nicht die Farbe (ausgegraut) eines übergeordneten Ordners für nur eine ignorierte Datei darin. Sie grauen es nur aus, wenn der Ordner selbst ignoriert wird.

Ich spreche eindeutig von übergeordneten Ordnern, nicht von Kindern. Hier habe ich dir ein Bild gemalt:

Hier ist das .gitignore im übergeordneten Verzeichnis, web als Referenz:

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

Meine Nachricht war eine Antwort auf @jriekens Antwort des WIP, hier , wo er sagt:

Welchen Kinderstatus sollte ein Elternteil abholen? Sollte das nach Wichtigkeit gehen? Mit Fehlern und Warnungen ist das einfach, aber was ist noch wichtiger, eine geänderte, eine nicht verfolgte oder eine ignorierte Datei?

Zeigt an, dass ein übergeordnetes Element einer "ignorierten" Datei/einem "ignorierten" Ordner einen Status haben kann, der nicht der Fall ist. Daher meine Antwort. Sie verwechseln das, was Sie visuell sehen, mit dem, was Git tatsächlich für seine Ignorierliste verwendet

➜  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 bedeutet, dass es in .gitignore mit einer speziellen Regel definiert ist, daher ist es nicht nur backend/web/assets/ und es sind speziell die zufällig benannten Asset-Verzeichnisse. Sie geben nicht jede einzelne ignorierte Datei an, wenn Sie mit einem Verzeichnis arbeiten, dessen Inhalt ignoriert wird. Zum Beispiel die Verzeichnisse vendor oder node_modules . Sie haben nur einen Eintrag im ignorierten Eintrag git status .

Im Dateibaum müssen Sie ALLEN Elementen (Dateien und Ordnern), die mit backend/web/assets/6f57f06b/ beginnen, eine Klasse von git-status-ignored hinzufügen.

Das CSS, das dem Dateibaumordner backend/web/assets/6f57f06b/ ist wie folgt (braucht derzeit 2 Regeln!):

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

UND

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

Hinweis: In der ersten Regel stimmen wir Titel nur mit einem = Zeichen überein, also genau! In der zweiten Regel gleichen wir alle Titel mit ^= , also dem Anfang des Strings, was auch alles tiefere (alle Kinder) entspricht.

Um ein Verzeichnis abzugleichen, sind 2 CSS-Regeln erforderlich. Ich denke, während wir dies tun, sollten wir title auf dem HTML-Element für Verzeichnisse machen, um einen nachgestellten Schrägstrich einzufügen. Sie können in diesem Screenshot sehen, wovon ich spreche:

Ja, Ihr Kommentar war passiv-aggressiv, da Sie unhöflich / schnarrend / beschissen waren, ohne die Worte tatsächlich zu sagen. Außerdem lagst du falsch. Niemand hat etwas über Kinder gesagt, und es ist nicht einmal das, worüber wir gesprochen haben.

@jrieken
So funktioniert mein Setup von Atom: "Bearbeitet" hat Vorrang vor "Hinzugefügt". Das Löschen einer Datei zeigt keinen Status an. Es gibt keinen Status für "inszeniert". Ich denke, andere sollten sich ihr Atom-Setup ansehen und sehen, ob dies auch für sie gilt und dass es nicht nur mein Setup ist. Es wäre gut, Code für jede Situation hinzuzufügen und den Benutzer so bearbeiten zu lassen, wie er es möchte.

Vielleicht fügen Sie mehrere Klassen hinzu, damit die übergeordneten Verzeichnisse den ganzen Baum hinauf "git-status-added" und "git status-modified" haben. Vielleicht sogar "git-status-deleted" einwerfen, wenn darunter etwas gelöscht wurde.

Dann verwenden Sie einfach CSS, um sie abzugleichen. Wenn Sie eine andere Farbe für .git-status-added.git-status-modified wünschen, können Sie eine orangefarbene Schrift mit einer grünen Unterstreichung verwenden (orange für geändert, grün für hinzugefügt). Wenn es nur die Klasse .git-status-added , dann mache die Schrift grün.

Es wäre nicht wirklich wichtig, wenn Sie ihnen erst Klassen hinzufügen, jeder kann CSS nach Belieben erstellen. Sie möchten jedoch eine "ziemlich gute" Standardeinstellung.

Ich werde den Ast ziehen, wenn ich etwas Zeit habe, und es mir ansehen.

Wie gehe ich mit Lint-Fehlern UND dem Git-Status um?

Atom setzt eine rote verschnörkelte Linie unter den Dateinamen, wie Sie hier sehen können:

Ich denke, wir sollten eine Klasse wie lint-error zum selben Element wie den Git-Status hinzufügen, die wir (und Designs) über unsere eigenen Stylesheets überschreiben können.

Also das div für das gleiche Element im Dateibaum, das ich oben als Beispiel verwendet habe (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>

Würde ungefähr so ​​aussehen, wenn wir sowohl einen Git-Status von git-status-edited als auch lint-error anwenden:

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

Dann könnten wir über CSS abgleichen:

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

Habt ihr einen Slack? Es gibt viele bearbeitete Dateien im Commit. Ich suche genau, wo Sie die Git-Statusfarbe auf den Dateibaum anwenden. Ist es in /extensions/git/src/repository.ts ?

Vielen Dank an alle und vielen Dank für die Klarstellung der Regeln für Änderungen, nicht verfolgte und ignorierte Dateien. Morgen werden Insider eine frühe Version davon liefern.

Einige Sachen

• Standardmäßig gibt es eine Kombination aus Farbe und Tasche.
  
  
  
  • Symbole aktivieren/deaktivieren mit: "explorer.decorations.badges": true|false
  
  
  • Farben aktivieren/deaktivieren mit "explorer.decorations.colors": true|false
  
  
• Farben werden im Dateibaum, im geöffneten Editorbereich und im SCM-Viewlet angezeigt
• Es gibt drei Farben für den Anfang. Sie können sie in der workbench.colorCustomizations -Einstellung anpassen. Die Farben sind gitDecoration.modifiedResourceForeground ,
  gitDecoration.deletedResourceForeground ,
  gitDecoration.untrackedResourceForeground ,
  gitDecoration.ignoredResourceForeground , und
  gitDecoration.conflictingResourceForeground
• Beachten Sie, dass sich die Namen der Einstellungen usw. wahrscheinlich ändern, neue Einstellungen hinzugefügt oder andere Einstellungen möglicherweise wieder entfernt werden.

Zu Ihrer Information – bearbeitet, um Änderungen widerzuspiegeln, die nach dem ersten Beitrag vorgenommen wurden

Ich denke, es ist besser, die Symbole auf der rechten Seite nicht auf die übergeordneten Verzeichnisse anzuwenden. Es kann zumindest eine Option geben.

Dies scheint in der Insider-Version aktualisiert worden zu sein, wobei scm.fileDecorations.useIcons und scm.fileDecorations.useColors durch scm.fileDecorations.enabled , was sowohl die Symbole als auch die Farben enthält.

Ich möchte nur die Farben haben, aber nicht die Symbole. IE das "alte" Verhalten von scm.fileDecorations.useIcons : false und scm.fileDecorations.useColors : true

Ich habe versucht, mit explorer.decorations.badges und explorer.decorations.colors experimentieren, aber sie scheinen keine Wirkung zu haben.

BEARBEITEN:
Ich verwende Version 1.18 Insider, Commit f1ee80be081b0d... unter Windows 10
(Es wäre schön, wenn der Text im Info-Dialog hervorgehoben werden könnte, damit Sie ihn kopieren können)

Danke für die Zusammenstellung @jrieken !

Hatte ein paar Gedanken:

• es sieht so aus, als ob die ausgewählte Farbe immer noch das alte Grau anstelle der Statusfarbe ist
• der Option zugestimmt, Symbole zu haben oder nicht (per @ FredrikFolkesson )
• mit den angezeigten Symbolen, wenn die geänderte/aktualisierte Farbe hell ist, sollte das 'M' oder 'U' dunkel sein (oder umgekehrt), damit der Kontrast da ist und es leichter zu lesen ist.

Ich freue mich darauf, die Datei main.js nicht bei jedem Build aktualisieren zu müssen, um die Farben zu erhalten !!!

Kleines Problem (ich verwende die neuesten Insider vom 16. Oktober), um zu berichten, @jrieken : Die Farbe des geänderten Dateinamens im Projektbaum wird nicht angezeigt, wenn diese Datei derzeit ausgewählt ist. Hier wird erwartet, dass die Farbe unabhängig davon, ob die Datei im Projektbaum ausgewählt ist oder nicht, dieselbe sein sollte (bezeichnet die geänderte Datei).

Ein weiteres Problem, das ich ansprechen möchte, ist die gleiche Farbcodierung nicht nur für den Projektbaum, sondern auch für den geöffneten Editorbereich. Derzeit gibt es keine Möglichkeit, im Abschnitt "Offene Editoren" zu sehen, welche der Dateien geändert wurden und welche nicht. Die Möglichkeit, schnell herauszufinden, welche Editoren für geänderte Dateien geeignet sind, ist SEHR praktisch, so dass man schnell zwischen den Dateien

Dies wäre eine großartige Funktion. Neu bei VSC von Atom und ich vermisse es sehr.

Ich bin auch gerade von Atom umgezogen und vermisse auch diese Funktion. Wann ist die Veröffentlichung mit dieser Funktion geplant?

Ebenso ist es vor allem wichtig, weil gitignored-Dateien in der Liste zu prominent sind und mit allem vermischt werden ...

Hallo, ich denke, wir brauchen auch einen Farbschlüssel, um die Vordergrundfarbe des Abzeichens zu ändern (#36246)

Danke an alle für das kontinuierliche Feedback. Ich habe meinen ersten zusammenfassenden Kommentar aktualisiert, um die jüngsten Änderungen widerzuspiegeln. Außerdem habe ich darauf geachtet, dass sich Änderungen an den Einstellungen ohne Neuladen widerspiegeln und die Statusfarbe gegenüber der Auswahlfarbe gewinnt.

Standardmäßig verwenden wir immer noch Farbe und ein Abzeichen, hauptsächlich aus zwei Gründen: Nicht jeder weiß sofort, was die Farbe bedeutet und das Abzeichen (mit seinem Tooltip) könnte dies selbsterklärend machen. Zweitens gibt es Leute wie mich, die Schwierigkeiten haben, diese Farben zu unterscheiden, und das Abzeichen soll dies ein wenig zugänglicher machen.

@jrieken Können Sie mir sagen, ob CSS-Klassen auf die Elemente im linken Dateibaum-Explorer angewendet werden? Dies würde die beste Erweiterbarkeit bieten und es den Theme-Entwicklern und uns persönlich leicht machen, die Farben anzupassen und zu überschreiben.

Beispiel: Wenn Ihre neuen Codekorrekturen eine Datei oder einen Ordner als hinzugefügt markieren, sollte eine Klasse wie git-status-added hinzugefügt werden. Dann können wir über unsere Stylesheets gezielt die Farben anpassen und nicht an dem festhalten, was Sie uns out of the box geben.

@WadeShuler Unsere Theme-Farben nennen . Es ist eine Umleitung, die bestimmten Dingen Namen gibt, wie z. B. editorLineNumber.foreground ist der Name der Vordergrundfarbe für Zeilennummern. Designs weisen diesen Namen Farben zu und der Editor übernimmt diese Werte beim Rendern. Schauen Sie sich dies an, um mehr Hintergrundinformationen zu erhalten: https://code.visualstudio.com/docs/getstarted/theme-color-reference

Bei den nächsten Insidern, voraussichtlich morgen 19., wird es ein spezielles Rendering für ignorierte Dateien geben ( git.color.ignored ) und Farben/Badges werden im Abschnitt "Editoren öffnen" angezeigt. Ich habe https://github.com/Microsoft/vscode/issues/178#issuecomment -335511695 entsprechend aktualisiert.

@jrieken Genial ! Wie wäre es mit einem Farbschlüssel für den Vordergrund der Git-Badges?
https://github.com/Microsoft/vscode/issues/178#issuecomment -336904514

Sehr gute Arbeit! Es ist großartig zu sehen, dass diese Funktion zu vscode kommt.

In der aktuellen Implementierung werden geänderte Dateien in einem Submodul noch nicht korrekt als geändert gekennzeichnet.

Im folgenden Beispiel:

Das Haupt-Repository enthält ein Untermodul in src/components/ . Im Untermodul wurden mehrere Dateien geändert. vscode meldet korrekt, dass src/components/ geändert wurde, aber es zeigt nicht an, welche Änderungen im Submodul vorgenommen wurden.

Atom erkennt modifizierte Dateien korrekt:

Dieses Problem hängt wahrscheinlich mit https://github.com/Microsoft/vscode/issues/7829 zusammen

@jrieken Genial ! Wie wäre es mit einem Farbschlüssel für den Vordergrund der Git-Badges?

@equinusocio Keine Sorge, es wird passieren, braucht aber etwas Nachdenken. Es ist für Oktober geplant

@jrieken Danke

@jrieken - Probleme in 1.18. Ich möchte mich für Ihre bisherige Arbeit bedanken. Ich habe gerade die v1.18 Insider getestet. Ich habe den obigen Thread überflogen, also entschuldigen Sie, wenn Sie bereits etwas für 1.19 in Arbeit haben, um das zu behandeln, was ich unten erwähne.

1) Der Status "hinzugefügt" im Dateibaum sieht aus wie "aktualisiert und nicht zusammengeführt" mit dem "U"-Badge. Hinzugefügte Dateien sollten ein "A"-Abzeichen haben.

2) Es gibt keine Farboption für git.color.added

3) Es gibt keine Farboption für git.color.ignored .

4) (Glitch) Es behandelt "hinzugefügte" Dateien als "nicht verfolgt". Ich habe eine "hinzugefügte" Datei inspiziert, und sie sieht aus wie im HTML-Code, sie denkt, sie sei nicht verfolgt. (der span Titel sagt "untracked" und die Klasse ist monaco-decorations-style-32 , das "U" Symbol). Dies ist offensichtlich, wenn die Farbe von workbench.colorCustomizations für git.color.untracked , da es die angeblich "hinzugefügten" Dateien steuert.

5) Unterstützen Sie den "R"-Status, für "umbenannt" oder verschoben, fügen Sie ein "R"-Abzeichen hinzu und fügen Sie die passende git.color.renamed Einstellung hinzu.

Danke, ich freue mich darauf, 1.19 auszuprobieren 👍

@danjjl Es gibt eine ausstehende PR für #7829.

Es gibt ein potenzielles Problem, denn wenn das Submodul geändert wird, weiß ich nicht, ob es (das Verzeichnis, das das Stammverzeichnis des Submoduls ist) als die Farbe des Verzeichnisstatus im Haupt-Git-Repository oder anders behandelt wird Farbe basierend auf den enthaltenen Dateien.

Das heißt, ich weiß nicht, ob die Farbe des Untermodulverzeichnisses auf "git status" im übergeordneten Verzeichnis oder im Untermodul basiert. Es kann sowieso egal sein.

@jrieken Hast du eine Slack-Gruppe oder woanders, um dieses Problem zu diskutieren? Ich kann helfen :) Ich konnte die aktuellen Änderungen aus dem Master-Zweig ziehen, entwickeln und debuggen. Ich habe die "hinzugefügten" Dateien korrigiert, die als "U" angezeigt werden, und sogar "gestufte" Unterstützung hinzugefügt. Da es mein erstes Mal im Projekt war, setze ich es zurück auf Master und mache es noch einmal. Ich habe eine Menge Änderungen vorgenommen und möchte wie ein Chirurg und nicht wie eine Atombombe reingehen.

Warum gibt es Schecks auf raw.x + raw.y gefolgt von Schecks auf raw.x dann auf raw.y ? Es scheint dazu zu führen, dass es 2 verschiedenen Status entspricht.

Warum gibt es 2 Statuskonstanten für ADDED / INDEX_ADDED , MODIFIED / INDEX_MODIFIED und einige andere? Ich verstehe all die verschiedenen Git-Status, aber es wäre sinnvoll, sie für den Endbenutzer zu behandeln, nicht die Benennung von Git-Status. ADDED sollte für das verwendet werden, was Sie jetzt als UNTRACKED um dann einen Einstellungscode von git.color.added . Ich denke, einige dieser Statuskonstanten sind doppelt vorhanden und sollten vereinfacht und bereinigt werden.

Ein Git-Status von _M <-- Unterstrich = Leerzeichen/nichts, würde mit raw.y übereinstimmen und Sie haben es als INDEX_MODIFIED . Dies ist falsch, der Status mit x = nichts und y = M steht für staged .

Aus irgendeinem Grund, manchmal zufällig, scheint es die Änderungen nicht widerzuspiegeln. Außerdem scheint es, als würden die Änderungen des Git-Status rekursiv von oben nach unten scannen. Wenn Sie ein großes Projekt haben, können Sie beobachten, wie der Status "Ignoriert" durch Ihre Ordner/Dateien tropft. Um es zu beschleunigen, schien es, tiefer zu navigieren, es für dieses Verzeichnis zu aktivieren und sie auszugrauen. -- Verlangsamt dieser Prozess das System/VSCode stark? Hat das jemand Benchmarking? Es ist wirklich nicht nötig, jede Datei/jeden Ordner durchzugehen, wenn das übergeordnete Element ignoriert wird. Die Kinder sollten ihren Status von ihren Eltern erhalten. -- Wenn Sie 5.000 Dateien ignored aber alle in 2 Verzeichnissen (zB: node_modules, Vendor), dann sollten wir keine 5.000 Dateien verarbeiten, sondern nur 2 Verzeichnisse, die das Aussehen ihrer Kinder kontrollieren.

Ich werde meine Änderungen später heute wiederholen und eine PR herausgeben.

Nochmals vielen Dank für Ihre Arbeit. Ich versuche nur zu helfen, anstatt dich zu belästigen, da ich es tatsächlich kann lol

@WadeShuler Ich kann einiges davon beantworten. Ich gehe davon aus, dass Sie in Repository.updateModelState() in repository.ts suchen. Wenn Sie sich die Überprüfungen raw.x + raw.y notieren, kehren sie alle zurück, sodass Sie dann die raw.x und raw.y eigentlich nicht ausführen können. Der Grund dafür, dass raw.x und raw.y getrennt sind, und der Grund für den INDEX_* ist, dass jeder INDEX_* inszeniert ist, es ändert sich nur das, was inszeniert wird. Wenn Sie INDEX durch STAGE ersetzen, ist es meiner Meinung nach sinnvoller, obwohl die verwendete Logik technisch korrekt ist. Siehe https://git-scm.com/docs/git-status , insbesondere die Tabelle "XY Bedeutung"
(BEARBEITEN: Wow, dass die Formatierung schlecht war. Geh einfach zum Original. Es ist eine Tabelle in Rot ungefähr auf halber Höhe.)
Das ist eindeutig das, was sie für diese ganze Sache verwenden.

Und ich denke, Sie irren sich im Fall _M, der mit MODIFIED, Index unmodified (dh nicht inszeniert) übereinstimmen würde. Es sei denn, Sie sehen sich ein Duplikat dieses Codes an anderer Stelle an.

@petkahl Danke, ich kenne das Kurzformat von Git Status . Ich habe es vor Wochen verwendet, um meinen vsc-git-Status zu korrigieren, um grundlegende Git-Status hinzuzufügen, bis dies offiziell gelöst wird.

Es ist (irgendwie) möglich, _M (Unterstrich = Leerzeichen) zu erhalten. Ich bin mir nicht sicher wie, warum, wann.. Ich habe das heute früher bekommen (sowie vor ein paar Wochen, als ich an meinem Gist arbeitete):

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

Jetzt, ein paar Stunden später, führe ich es aus und erhalte "A". Ich weiß nicht, was sich seitdem geändert hat..

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

Als ich für meinen Gist recherchierte, kam ich zu dem Schluss, dass es möglich ist, "A_" und "_M" für inszeniert zu bekommen. Ich hatte auch eine Site gefunden, die den Status viel klarer aufgeschlüsselt hatte als die git-status-Dokumente, ich kann sie einfach nicht mehr finden lol.

Sie können auch "AM" für eine bereitgestellte und geänderte Datei erhalten. Erstellen Sie eine neue leere Datei, fügen Sie sie hinzu (stage it), bearbeiten Sie die Datei und speichern Sie, überprüfen Sie den Status:

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

Sollte dies also 2 Abzeichen haben, "[S][M]" ? Ich möchte lieber wissen, welche Dateien ich inszeniert habe. Es ist nützlich beim Rosinenpicken. Es kann nützlich sein, noch zu sehen, ob Sie eine bereitgestellte Datei geändert haben. Es sollte zumindest ein inszeniertes Abzeichen haben.

@WadeShuler Ich kann _M durchgängig erhalten, indem ich
so:
Erstelle Datei: ??
git Datei A_ hinzufügen
git commit (nicht im Status, aber das Äquivalent von space space)
Ändern Sie die Datei: _M
git Datei hinzufügen M_
noch einmal ändern: MM

Ich habe nicht wirklich eine Meinung zu den Abzeichen, wenn es zwei hat. Ich checke nie ein, ohne auf das Statusfenster zu schauen, das es klar aufschlüsselt, genau wie es der normale Git-Status tut. Vielleicht nur eine Einstellung, mit der Sie auswählen können, welche Priorität hat? Ich konnte Argumente für beides sehen. Oder zwei Abzeichen, schätze ich. Wäre das bei der Färbung ähnlich?

Ich habe Staged Unterstützung hinzugefügt. Sie können die Änderungen hier sehen: WadeShuler/ vscode:gitstatus-fix . Ich habe auch einige der Abzeichen auf der Registerkarte Git-Status etwas besser aussehen lassen, indem ich sie etwas größer gemacht habe.

Aus irgendeinem Grund wurde das Verdunkeln/Ignorieren des Verzeichnisses vendor , aber der Inhalt darin ist immer noch ausgegraut und wird ignoriert. Ich verstehe nicht, warum meine einfache Änderung das vendor Verzeichnis nicht mehr ausgegraut hat? Das ist das einzige Problem mit dem, was ich gerade gemacht habe, und warum ich noch keine PR herausgegeben habe...

Wenn Farben/Symbole für bereitgestellte Dateien eingeschlossen werden sollen, sollte dies definitiv optional sein. Persönlich würde ich in meiner Liste lieber nicht als eine andere Farbe als die ursprüngliche neue / geänderte Farbe inszeniert sehen.

Sobald Sie mit dem Einbinden von Staging beginnen, kann es schnell kompliziert werden, da es die Möglichkeit gibt, alle Kombinationen und Permutationen von neu / neu inszeniert / modifiziert / modifiziert-staged / modifiziert-staged-modifiziert / neu inszeniert-modifiziert usw. , was zu einer riesigen Farbmatrix und Verwirrung führen wird.

Ich stimme dafür, dass wir die Sache nicht zu kompliziert machen.

Ich stimme @dseipp zu. Das ist genau der Grund, warum ich die Unterstützung für inszenierte Dateien in meinem ersten Hack nicht zusammengeführt habe, da ich keine Verwendung für das Einfärben von inszenierten Dateien sah.

Der Zweck der farblichen Hervorhebung besteht darin, dass ich neue/geänderte Dateien auf einen Blick im Datei-Explorer finden kann. Wenn ich einige Dateien inszeniere, geschieht dies normalerweise vor dem Commit oder wenn ich anderweitig damit fertig bin, also habe ich keine Verwendung dafür, dass sie normal eingefärbt werden.

Wenn wir für jeden möglichen Typ von Git-Status Farbe hinzufügen, sieht der Datei-Explorer wie ein Weihnachtsbaum aus und es wird sehr verwirrend zu sehen, was tatsächlich vor sich geht.

@jrieken Noch ein Fehlerbericht, passiert bei den neuesten Insidern:

• VSCode-Version: Code - Insider 1.18.0-insider (82dcf9835265cd0a45ec135587ae2a82673f1c8f, 2017-10-20T04:24:25.632Z)
• Betriebssystemversion: Windows_NT x64 10.0.15063

Grundsätzlich "vergisst" VS Code von Zeit zu Zeit, dass einige Dateien geändert werden und entsprechend eingefärbt werden müssen. Zum Beispiel habe ich im Moment 6 Dateien geändert. VS Code (korrekt) zeigt die Zahl "6" auf dem Git-Button. Aber im Projektdateibaum sehe ich nur EINE Datei in Gelb, die anderen fünf Dateien sehen aus, als wären sie nicht geändert worden. Interessanterweise sind alle 6 Dateien im Bereich der geöffneten Editoren richtig eingefärbt.

@dseipp Es könnte optional sein. Allerdings werden Sie die "inszenierte" Farbe nie sehen, bis Sie Dateien inszenieren ... Sie wird also nicht einmal in 99% der Fälle gesehen und sollte niemanden wirklich stören.

@karabaja4 Ich bin anderer Meinung, dass es keinen Nutzen hat. Sie haben darauf hingewiesen, dass Sie nie eine inszenierte Farbgebung verwenden / bemerken / benötigen ...

Der Zweck der farblichen Hervorhebung besteht darin, dass ich neue/geänderte Dateien auf einen Blick im Datei-Explorer finden kann. Wenn ich einige Dateien inszeniere, geschieht dies normalerweise vor dem Commit oder wenn ich anderweitig damit fertig bin, also habe ich keine Verwendung dafür, dass sie normal eingefärbt werden.

Selbst wenn diese Funktion hinzugefügt wird, sollte es Sie nicht stören...

In der Lage zu sein, inszenierte Dateien zu sehen, hilft bei der Rosinenauswahl, was Sie begehen möchten. Wenn wir 100 Dateien geändert haben und diese gruppieren müssen, können wir den Dateibaum durchsuchen und leicht sehen, was bereitgestellt wird, und die verpassten Dateien abfangen, um sicherzustellen, dass sie sich im selben Commit befinden.

Wie oft haben Sie eine Handvoll Dateien übertragen und dann festgestellt, dass Sie eine verpasst haben? Sie haben dann 2 Optionen, ändern Sie Ihren letzten Commit, um die fehlenden Dateien einzuschließen, oder machen Sie einen neuen Commit. Bei der Arbeit mit Teams ist es sauberer und weniger verwirrend, sie im selben Commit zu haben.

An dem inszenierten Punkt spielt es keine Rolle, ob die Datei hinzugefügt, geändert oder anderweitig verwendet wurde.

Um ehrlich zu sein, ist die Art und Weise, wie Visual Studio Code mit Git umgeht, schlampig und fehlerhaft. Große Dateibäume, Sie können buchstäblich zusehen, wie die Farbe durch die Dateien / Ordner tropft. Es lässt zufällig die Farbe fallen ...

Ich denke, der gesamte Git-Support hat eine Neufassung von Grund auf fallen lassen.

Ich möchte auch meine Unterstützung für das Einfärben von inszenierten Dateien zum Ausdruck bringen (optional ist in Ordnung, solange ich es aktivieren kann).

Hier ist mein Workflow: Ich beginne mit der Arbeit an einem Feature/Bugfix, bringe es in den Zustand "OKish", was bedeutet, dass der Code mehr oder weniger funktioniert, aber einige Polituren/Optimierungen/Bereinigungen oder Refactorings erfordert. In diesem Moment inszeniere ich meine Veränderungen. Führen Sie dann die Bereinigung und das Refactoring durch. Wenn das Refactoring fehlschlägt oder zu unordentlich wird, kehre ich einfach in den bereitgestellten Zustand zurück.

Es ist sehr vorteilhaft, sehen zu können, welche Dateien ich gerade ändere, und wenn ich die Änderungen vorführe, möchte ich nicht all diese Informationen verlieren und zum einfachen Baum ohne Farben gelangen.

@vvs Ich stimme zu, dass inszenierte Dateien ihre Farben nicht verlieren. Farben sollten bleiben, bis sie festgeschrieben sind. Ich würde es einfach vorziehen, dass die inszenierte Farbe die neuen/modifizierten Farben behält und die zusätzlichen inszenierten Farben optional bleiben.

Vielleicht kann Staged die gleichen Farben beibehalten, aber nur eine Art Hervorhebung oder Fettdruck hinzufügen, um einen Kontrast zu erzielen.

Es könnte hilfreich sein, sich den Stand der Technik anzuschauen. Ich erinnere mich nicht, einen inszenierten Indikator gesehen zu haben, aber vielleicht haben sich die Zeiten geändert

Sind die Icons im Datei-Explorer für modifizierte/nicht bereitgestellte/... Dateien wirklich notwendig? Ich habe einige Probleme mit der Aufmerksamkeit, daher lenken mich Farben und Symbole sehr leicht ab. Könnte es nicht optional und standardmäßig deaktiviert sein? Bin ich der einzige, der sich von ihnen ablenken lässt?

Aus Sicht der Benutzerfreundlichkeit ist weniger manchmal mehr, und viele werden sich nicht die Mühe machen, nach der Option zu suchen, diese Dinge zu deaktivieren, und werden weiter leiden oder sogar die Redakteure wechseln. Ich denke, es wäre eine gute Sache, dies durchzudenken und zu entscheiden, ob dies für eine bessere UX wirklich notwendig ist (was meiner Meinung nach der Sinn dieser Symbole ist).

* Ich hatte nicht die Zeit, jeden Kommentar zu diesem Thema zu lesen, also bitte sagen Sie mir, wenn meine Frage etwas ist, das bereits besprochen wurde, und ich werde mir die Zeit nehmen, alles so schnell wie möglich zu lesen, um mich darauf einzulassen Was würde gesagt. Vielen Dank.

Ich denke, es wäre eine gute Sache, dies durchzudenken und zu entscheiden, ob dies für eine bessere UX wirklich notwendig ist (was meiner Meinung nach der Sinn dieser Symbole ist).

https://github.com/Microsoft/vscode/issues/178#issuecomment -336960308 Deshalb haben wir standardmäßig Farben und Abzeichen. Ich bin damit einverstanden, dass die Benutzeroberfläche dadurch etwas überladener wird und offen für Vorschläge ist, die zugänglich/inklusive, aber auch glatt und sauber sind.

@jrieken Danke! Können Sie mich bitte auf den Commit hinweisen, der die Abzeichen eingeführt hat? Ich werde versuchen, etwas zu finden, das für beide Probleme von Vorteil wäre (wenn ich Schwierigkeiten habe, Farben zu sehen oder nicht zu wissen, wofür es ist, und Probleme mit Ablenkung).

@jrieken Nehmen wir eine Seite aus Xcode und machen die Abzeichen subtiler.

Abzeichen sind nützlich, um Anfängern Hinweise zu geben, aber es wird unübersichtlich, nachdem die Farben gelernt wurden.

Für zusätzlichen Fahrradabwurf bevorzuge ich Abzeichen in git.color.ignored (_left_ oben), da sie die gleiche visuelle Bedeutung haben. Das heißt, verschwinden, aber nicht verschwinden, falls ich dich brauche.

Wenn wir subtile Badges implementieren, sollten die Badges in der Seitenleiste der Quellcodeverwaltung aus Konsistenzgründen aktualisiert werden.

In welche Richtung die Badge-Diskussion auch gehen mag, könnte das Badge-Design zumindest mit denen in der Git-Sidebar übereinstimmen? Es fühlt sich etwas unzusammenhängend an, ein Design für die Explorer-Sidebar und ein anderes für die Git-Sidebar zu haben.

Ich mag den Einzelbuchstaben-Vorschlag von @jayjun. Ich werde es heute versuchen.

Wenn wir subtile Badges implementieren, sollten die Badges in der Seitenleiste der Quellcodeverwaltung aus Konsistenzgründen aktualisiert werden.

Das wird passieren, das steht auf meinem Plan für Oktober.

Ich habe https://github.com/Microsoft/vscode/issues/178#issuecomment -335511695 mit den neuesten Screenshots und Farbnamen aktualisiert. Außerdem zeigen wir mit dem Insider von morgen die gleichen Badges im SCM-Viewlet, jedoch keine farbigen Labels. Gefällt mir

Es sieht besser aus @jrieken - Danke für deine kontinuierliche Mühe. Ich finde die Abzeichen sehen viel besser aus!

Sollte das Abzeichen U ? Ich denke, die Community sollte sich einmischen. Das U lässt mich zuerst an updated denken. Ich weiß, dass es in der Git-Terminologie untracked , aber ich denke, dass A passender ist, besonders für diejenigen, die mit den zugrunde liegenden Begriffen nicht vertraut sind, dass U wird. - Ich persönlich stimme für A für hinzugefügt. Wie in, wurde es Ihrem Repository hinzugefügt.

Dann Unterstützung für staged (optional über Einstellungen) und es ist ziemlich nah 👍

@WadeShuler , wie wäre es mit einem Fragezeichen (?) für nicht verfolgt? Ich mag A nicht, da es eine andere Bedeutung für Git hat, als hier gemeint ist, zumindest in meinen Augen.

Edit: Aber ich stimme zu, dass U verwirrend sein könnte.

Ich denke, mit einem Fragezeichen wäre ich gut. Ich glaube jedoch nicht, dass Code
unterstützt nur Git, oder? Ich denke, wir sollten es nicht visuell betrachten
den Editor als „Git“, aber generell mehr Versionskontrolle.

Was auch immer der Fall ist, ich mag "U" wirklich nicht lol

Am Di, 24.10.2017 um 14:20 Uhr Peter Kahle [email protected]
schrieb:

@WadeShuler https://github.com/wadeshuler , wie wäre es mit einem Fragezeichen
(?) für nicht verfolgt? Ich mag A nicht, da es eine andere Bedeutung hat für
git als hier gemeint ist, zumindest in meinen Augen.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/Microsoft/vscode/issues/178#issuecomment-339084261 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AJHVkJJNzw89umFiPB0BmgQAZYJNXTHzks5svip7gaJpZM4GlYyH
.

Fair genug, es sollte agnostisch sein. Aber "Unbekannt für das Versionskontrollsystem" als ? Für mich ergibt das Sinn. Aber N (für Neu) könnte auch funktionieren, und ich kann mir keine Überladungen vorstellen, obwohl ich sicher bin, dass jemand anderes dies tut.

Ja, @jrieken , Ihre Bemühungen werden sehr geschätzt! Sieht richtig gut aus! Die dezenten Abzeichen sind ein Pluspunkt.

Ich bin mit @WadeShuler und @petkahl zusammen , die das U in etwas anderes ändern möchten. Das 'N' oder '?' Arbeit. Ich tendiere jedoch zum N, da es dann 'neu und 'modifiziert' wäre.

Ich freue mich, dass das zusammenkommt!

Funktioniert workbench.colorCustomizations.git.color.ignored für alle?
Ich bin auf 1.18.0-insider zuletzt aktualisiert und die ignorierte Farbe wird immer noch nicht aufgenommen. Außerdem scheinen "_deleted_" und "_conflict_" noch nicht zu funktionieren... vielleicht mit dem morgigen Update,
Aber was mich stört, ist die ignorierte Farbe. Der Dateiname sieht genauso aus wie eine versionierte - unmodifizierte Datei, d. h. es wird keine spezielle Farbe angewendet.
Hinweis: Das Repo im Screenshot enthält keinerlei nachverfolgte Dateien. Alle Dateien sind nicht verfolgt. Sobald ich "_shared.module.ts_" von .gitignore entferne, wird es in Braun angezeigt (meine nicht verfolgte Farbeinstellung).

Sollte das Abzeichen jedoch U sein? Ich denke, die Community sollte sich einmischen. Das U lässt mich zuerst auf den neuesten Stand denken. Ich weiß, dass es in der Git-Terminologie nicht verfolgt wird

Wir haben 'U' schon früher verwendet, dies ist nicht das richtige Thema, um zu diskutieren, was besser ist, aber ich denke, Git-Benutzer kennen die Terminologie und für andere SCM-Anbieter können/sollten andere Buchstaben/Symbole verwendet werden (und das ist heute der Fall).

Diese Funktion wurde nicht hinzugefügt und ich bin seitdem in diesem Thread aktiv
es ging vorwärts. Ich habe das „U“-Abzeichen von Anfang an erwähnt.

In diesem Thread geht es darum, das gesamte Feature zu entwickeln und auszubügeln, da
es ist neu. Wenn Schriftfarbe, Abzeichenstil und Abzeichenfarben akzeptabel sind
in diesem Thread zu diskutieren, dann auch die Briefe.

Wo sonst, außerhalb dieses Threads, haben wir "U" verwendet?

Wo sonst, außerhalb dieses Threads, haben wir "U" verwendet?

Überprüfen Sie Stable, nicht Insider, und das SCM-Viewlet mit git. Es verwendet eine U für u - Dateien ntracked.

@WadeShuler @jrieken Das aktuelle SCM-Viewlet (1.17.2) markiert eine _nicht verfolgte Datei_ mit einem grauen U und eine _hinzugefügte Datei_ mit einem grünen A . git status zeigt _hinzugefügte (bereitgestellte) Dateien_ in ANSI-Grün an .

Ich verstehe also die Verwechslung mit einem grünen U für eine _unverfolgte Datei_. Ich sehe auch voraus, dass meine Augen schmerzen, weil sich grüne U s mit grünem A mischen.

Atom färbt sowohl ungetrackte als auch bereitgestellte neue Dateien als grün und Xcode markiert hinzugefügte Dateien als A , solange es sich um eine neue Datei handelt. Beides hat mich nie im Geringsten gestört (aber ein grünes U schon).

Also werde ich alles dafür tun, grüne A s für nicht verfolgte _und_ neue bereitgestellte Dateien zu verwenden.

Lassen Sie uns das 'U' vs 'A' vs '?' Diskussion unter https://github.com/Microsoft/vscode/issues/36912. Vielen Dank.

Ich stimme zu. Ich denke, es ist besser, mit den Buchstaben fortzufahren, die heute in der Benutzeroberfläche verwendet werden. Ich mag das 'U' auch nicht, aber ich denke, dies liegt außerhalb des Rahmens dieser Funktionsanfrage. Wenn sich dies geändert hat, sollte sich dies im gesamten Programm ändern.

OK, das ist ein riesiger Thread und ich habe nur Zeit, ihn zu überfliegen, also sage ich hier einfach: Ich hoffe, es gibt eine Einstellung, um dies zu deaktivieren. Ich bevorzuge alle Dateinamen in der gleichen Farbe und wenn ich ihren Status sehen muss, gebe ich git status . :-)

Wird dieses Produkt aufgegeben? Scheint zu sein.

Derzeit scheint list.activeSelectionForeground Vorrang vor dem Git-Status-Styling zu haben, sodass die Git-Statusfarben in der ausgewählten Datei nicht zu sehen sind. Ich finde es nützlich, diese Informationen zu haben, auch für die aktuell ausgewählte Datei. Besteht die Möglichkeit, dass das Git-Status-Styling Priorität hat, wenn explorer.decorations.colors wahr ist?
Dieses Verhalten wurde bei Insidern 1.18 8dfa696 beobachtet.

Derzeit scheint list.activeSelectionForeground Vorrang vor dem Git-Status-Styling zu haben, sodass die Git-Statusfarben in der ausgewählten Datei nicht zu sehen sind.

In der Tat das gleiche hier bei den neuesten Insidern (gerade aktualisiert). Wenn ich im Projektbaum auf den Dateinamen klicke, ändert sich die Farbe des Dateieintrags (zB von gelb/modifiziert auf neutral). Ich denke auch, dass dies ein ziemlich verwirrendes Verhalten ist. Die Farbe der Datei sollte sich nicht ändern, wenn der Benutzer auf die Datei klickt.

Übrigens, das gleiche Problem mit der Liste der geöffneten Dateien, wenn Sie dort auf die Datei klicken, wird die git-Statusfarbe durch die neutrale Auswahlfarbe ersetzt.

Übrigens, das gleiche Problem mit der Liste der geöffneten Dateien, wenn Sie dort auf die Datei klicken, wird die git-Statusfarbe durch die neutrale Auswahlfarbe ersetzt.

Nun, es wurde mit Absicht gemacht, weil die Auswahl-Vordergrundfarbe oft mit den Dekorationsfarben kollidiert. Das Hinzufügen weiterer Farben wie git.untrackedSelectedForeground und git.untrackedFocusedForeground schien uns nicht sehr ansprechend. Daher lassen wir die Auswahlfarbe gewinnen, wenn ein Element ausgewählt wird und den Fokus hat.

Atom scheint damit kein Problem zu haben....

Es sind keine neuen Einstellungen erforderlich... Die Designs werden aktualisiert, um sich an die Hintergrundfarbe des ausgewählten Elements anzupassen. Diejenigen, die dies nicht tun, wird die Community entscheiden, diese Themen nicht zu verwenden.

Ich habe es nicht überprüft, aber ich hoffe, die "Abzeichen" (dh: U, M) sind keine SVG-Dateien. Sie sollten nur Rohtext sein, der gestylt/eingefärbt werden kann.

Ehrlich gesagt, VSCode hätte für diese Dinge einfach Stylesheets anstelle von klobigen Konfigurationseinstellungen verwenden sollen. Es überkomplizierte einen ziemlich einfachen Prozess.

@WadeShuler Es gibt Auswahl und Fokus und da ich in Ihrem Screenshot einen Editor-Cursor sehe, glaube ich, dass Ihr Element nur ausgewählt und nicht fokussiert ist. Tatsächlich sehe ich bei Atom keinen Unterschied zwischen ausgewählt und fokussiert. So ist es in VS Code

ausgewählt, aber nicht fokussiert

ausgewählt und fokussiert

@jrieken Ich habe es doppelt überprüft, und in meinem Atom liefern ausgewählte vs. fokussierte das gleiche Ergebnis. Es verliert nie die Schriftfarbe yellow im linken Datei-Explorer-Fenster. In Ihrem zweiten Screenshot geht die Farbe red von test.foo , was das Problem ist.

Ich habe die standardmäßigen dunklen und hellen Atom-Designs sowie etwa 3 andere Designs ausprobiert. Meine Standardeinstellung (wie Sie in meiner SS sehen) ist Seti (sowohl Benutzeroberfläche als auch Design). Ich kann Atom nicht dazu bringen, die Farbe yellow aus dem Datei-Explorer zu löschen, egal was ich tue. Atom-Version 1.21.2.

Ausgewählt

Ausgewählt & Fokussiert

Standardmäßig sollte VS Code die Git-Statusfarbe unabhängig von ausgewählten oder fokussierten Zuständen beibehalten.

Wenn Ihr Problem Themen sind, ist es nicht Ihr Problem. Es liegt in der Verantwortung der Theme-Entwickler, diese zu aktualisieren und anzupassen.

Nebenbei bemerkt: Ich habe mir weder die neuesten Insider noch den Code angesehen, aber die git ignored Dateien sollten opacity keine Schriftfarbe verwenden, also ist es immer x dunkler als normale Dateien, unabhängig von ihrer Farbe.

@WadeShuler vielen Dank für Ihr Feedback, wie Themenmanager mit ihrem Geschäft umgehen sollten! Wie kann das VSCode-Team es wagen, eine API bereitzustellen, die ihnen dabei hilft? Diese faulen Entwickler!

@fernandofleury Niemand hat etwas darüber gesagt, dass Theme-Managern keine API zur Verfügung gestellt wird, um sie zu verwalten. Mein Beitrag sagte nichts dergleichen. Ihr bissiger Kommentar ist also einfach ungültig und ungerechtfertigt.

@jrieken sagte:

Nun, es wurde mit Absicht gemacht, weil die Auswahl-Vordergrundfarbe oft mit den Dekorationsfarben kollidiert.

Ich sagte:

Wenn Ihr Problem Themen sind, ist es nicht Ihr Problem. Es liegt in der Verantwortung der Theme-Entwickler, diese zu aktualisieren und anzupassen.

Das Problem wäre ein Konflikt zwischen der Vordergrundfarbe (eigentlich ist es eine Hintergrundfarbe) des Datei- / Ordnerbaumelements (normal, ausgewählt, fokussiert) und der Schriftfarbenauswahl für die verschiedenen Git-Status.

Dies _wäre_ in der Verantwortung der Theme-Entwickler. Sie sollten sowohl die Vordergrundfarben der Elemente im Baum als auch die Schriftfarben für die verschiedenen Git-Status wählen, damit sie nicht in Konflikt geraten.

Beispiel: Ein Theme-Entwickler hat ThemeX und seine Schriftfarbe für die Elemente im Explorer-Dateibaum ist yellow . Nun, seine Standard-Schriftfarbe würde mit der Standard-Git-Statusfarbe von yellow kollidieren. Sie könnten nicht mehr erkennen, welche Dateien geändert wurden. Dies wäre also die Verantwortung der Theme-Entwickler! -- Das gleiche gilt für die Hintergrundfarbe für ausgewählte/ausgewählte Elemente im Explorer-Dateibaum im Vergleich zu den Schriftfarben der Git-Status.

Wird das jetzt verschoben?

@IljaDaderko Ich glaube nicht, da es in der kommenden Release Note v1.18 der nächsten Stable-Version

@IljaDaderko VSCode v1.18 ist bereits erschienen und enthält die hier besprochenen Änderungen.

Sollen ignorierte Dateifarben Teil des Updates v1.18 sein? In den Dokumenten steht, dass gitDecoration.ignoredResourceForeground verwendet werden kann, um ignorierte Dateien einzufärben, aber bisher konnte ich nicht sehen, dass sich dies auf irgendetwas auswirkt. Modifizierte / nicht verfolgte Färbung funktioniert jedoch großartig. Dies ist auf Stable 1.18.0, Windows.

Das gleiche hier (über ignorierte Farbe). Hat bei mir auch nicht funktioniert, seit diese ganze Git-Implementierung begonnen hat. Insider verwenden.
Alles, was gitDecoration.ignoredResourceForeground tut, ist ignorierte Dateien beim Färben zu ignorieren :)

Es funktioniert für mich und es sieht SPEKTAKULÄR aus.

Endlich ist es da

@arxpoetica Das bekomme ich:

Wie kann es bei einigen funktionieren und bei anderen nicht, ich verstehe es nicht. Es ist nur diese eine Einstellung gitDecoration.ignoredResourceForeground
Bin ich der einzige bei dem es nicht funktioniert? Wirklich sonst niemand? :) Oh, und @Shurelia
Hat jemand anderes (wir, Benutzer) tatsächlich getestet, ob die ignorierte Farbe eingestellt wird, bevor er sagt, dass es funktioniert?

Betriebssystem: Windows 10 PRO (1709)
VSCode: 1.19.0-insider (gerade früher aktualisiert)
Gleiches auf meinem Arbeits-Laptop und Heim-Desktop.

Liegt es an Insidern? Wie kann ich es verwenden?

Herzlichen Glückwunsch, alle!

@nkkollaw Sowohl in 😎 Insidern als auch im Stall (1.18)

@MrCroft Bitte besprechen Sie git-ignore-Probleme hier: https://github.com/Microsoft/vscode/issues/37857

Da wir diese Funktion in unserem neuesten stabilen Build bereitgestellt haben, ist es an der Zeit, dieses Problem zu schließen und zu sperren. Bitte erstellen Sie neue Issues für Themendiskussionen und Fehlerberichte. Probleme in diesem Bereich werden mit dem file-decorations -Label gekennzeichnet.

Allen, vielen Dank für das großartige und kontinuierliche Feedback, das dieses Feature zu dem gemacht hat, was es ist!

Um meinen vorherigen Kommentar zusammenzufassen und zu wiederholen.

Einige Sachen

• Standardmäßig gibt es eine Kombination aus Farbe und Tasche.
  
  
  
  • Symbole aktivieren/deaktivieren mit: "explorer.decorations.badges": true|false
  
  
  • Farben aktivieren/deaktivieren mit "explorer.decorations.colors": true|false
  
  
• Farben werden im Dateibaum, im geöffneten Editorbereich und im SCM-Viewlet angezeigt
• Es gibt drei Farben für den Anfang. Sie können sie in der workbench.colorCustomizations -Einstellung anpassen. Die Farben sind gitDecoration.modifiedResourceForeground ,
  gitDecoration.deletedResourceForeground ,
  gitDecoration.untrackedResourceForeground ,
  gitDecoration.ignoredResourceForeground , und
  gitDecoration.conflictingResourceForeground