Vscode: Statut de Git dans l'explorateur de fichiers

Cr√©√© le 19 nov. 2015  ¬∑  247Commentaires  ¬∑  Source: microsoft/vscode

Similaire à ce que fournit atom dans l'explorateur de projet :

  1. Les nouveaux fichiers sont affichés en vert.
  2. Les modifiés sont affichés en jaune/orange.
  3. Les fichiers ignorés sont affichés en transparence.

Merci

feature-request file-decorations file-explorer git

Commentaire le plus utile

J'ajoute quelques captures d'écran pour vous aider :

Atome par défaut :

screen shot 2016-12-15 at 12 29 11

VSCode par défaut :

screen shot 2017-01-05 at 10 55 23

Tous les 247 commentaires

  • 1

Ce serait cool si cela √©tait expos√© comme une extension d'une mani√®re ou d'une autre. Je crains que dans certains cas, l'arbre puisse √™tre un peu pollu√© par la couleur et ressembler √† un sapin de No√ęl. Ou sinon, au moins avoir la possibilit√© de l'activer et de le d√©sactiver.

Oui je suis d'accord. J'ai créé un problème distinct pour que cela soit exposé dans l'API d'extension (voir #1394).

+1

J'adorerais √ßa aussi. L'onglet Git est tr√®s pratique mais c'est dans un autre but - avoir des couleurs comme dans Atom serait tr√®s compl√©mentaire pour voir en un coup d'Ňďil ce qui a chang√© et o√Ļ (avec la couleur se propageant automatiquement jusqu'au r√©pertoire sup√©rieur). C'est probablement la fonctionnalit√© qui me manque le plus d'Atom.

Habituellement, vous n'avez pas des dizaines ou des centaines de fichiers modifi√©s non valid√©s, il est donc peu probable qu'il ressemble √† un sapin de No√ęl :)

Il semble donc que le PR pour cela a été fermé. @bpasero @joaomoreno - des mises à jour sur l'état de ce travail ?

Aucune mise à jour...

Merci beaucoup pour l'intérêt que vous portez à ce problème ! Il est actuellement affecté au backlog. Chaque mois, nous choisissons des éléments du backlog pour planifier l'itération en cours. Veuillez consulter https://github.com/Microsoft/vscode/wiki/Issue-Tracking#planning pour plus d'informations.

√Čtant donn√© que nous sommes une petite √©quipe de d√©veloppeurs, il n'y a qu'un nombre limit√© de demandes de fonctionnalit√©s et de probl√®mes sur lesquels nous pouvons travailler pour un jalon. N√©anmoins, nous accueillons toujours les demandes de tirage et sommes heureux de les accepter si elles r√©pondent √† nos normes de qualit√©.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Veuillez arrêter d'écrire +1 . Il envoie un e-mail à tout le monde dans le problème. Utilisez les réactions emoji sur le premier commentaire.

+1

Bonjour, avez-vous des nouvelles de cette demande de fonctionnalité ? J'ai commencé à utiliser le vscode aujourd'hui et j'adore déjà mais les couleurs qui indiquent les changements me manquent vraiment
Félicitations pour votre travail

+1

Lors de la mise en Ňďuvre de cela, veuillez consid√©rer 206

J'ajoute quelques captures d'écran pour vous aider :

Atome par défaut :

screen shot 2016-12-15 at 12 29 11

VSCode par défaut :

screen shot 2017-01-05 at 10 55 23

+1

+1

Ce serait très utile.

il est d√©j√† possible de modifier la fa√ßon dont les fichiers et les ic√īnes sont r√©pertori√©s dans l'arborescence des fichiers.
Cette extension le fait
https://github.com/robertohuertasm/vscode-icons.

Il ne colore pas les noms de fichiers cependant

+1

+1

y a-t-il des changements ? Cette fonctionnalité m'empêche de passer d'Atom. :(

Je viens de m'éloigner d'Atom car les performances sont bien meilleures dans VSC. Cependant, c'est une fonctionnalité de luxe qui me manque dans VSC.

+1

Je pense que ce serait bien d'avoir cela comme paramètre intégré (par exemple git.colorExplorer ) au lieu d'une extension.

@arkon existe-t-il une telle extension ? Je n'en ai pas trouvé.

Très probablement l'explorateur de fichiers n'a pas d'API pour le modifier en fonction
pour git changer. Une extension me conviendrait.

Le vendredi 3 f√©vrier 2017, 07:52 Rahul [email protected] a √©crit :

@arkon https://github.com/arkon existe-t-il une telle extension ? je ne pouvais pas
en trouver.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/Microsoft/vscode/issues/178#issuecomment-277177373 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AEQJ1eoLm7Sp59a2hE0tIFQnb0Q5cJnSks5rYs6tgaJpZM4GlYyH
.

@rahulnever2far Non, c'était juste une suggestion puisqu'il avait été suggéré précédemment qu'elle pourrait être exposée en tant

J'ai récemment décidé de passer à VSCode et cette fonctionnalité me manque vraiment

S'il-vous-plait ajoutez. Ajoute de la friction à la productivité lorsque vous essayez de sauter d'Atom.

@KozhokarAlex @bhudgens et autres¬†: cliquez sur l'ic√īne pouce lev√© dans le premier message pour montrer aux d√©veloppeurs que vous demandez cette fonctionnalit√©. Ils trient les probl√®mes par pouce lev√© pour d√©terminer quelles demandes de fonctionnalit√©s sont les plus populaires.

Comme vous pouvez le voir à partir de ce type de tri des problèmes, ce problème est la 3ème fonctionnalité la plus demandée actuellement.

Pouces vers le haut. R√©cemment venu d'Atom..j'esp√®re le voir bient√īt dans VSCode!

Ah merci @joaomoreno !

Veuillez également ajouter le même statut de coloration/arrêt à QuickOpen, pas seulement FileExplorer.
De cette façon, les fichiers d'ouverture peuvent être filtrés visuellement en fonction des fichiers déjà modifiés.

Qu'est-ce qui se passe avec ça? pourquoi les mainteneurs ne fusionnent-ils pas @joaomoreno PR ? y a-t-il un plugin que nous pouvons utiliser maintenant? c'est juste un plan stupide

@SOSANA Vous ne savez pas ce que vous entendez par RP, à quel RP faites-vous référence ?

2824 ouvre la porte pour réparer celui-ci, alors soyez patient un peu plus.

@SOSANA c'est un probl√®me, pas un PR ūü§£

+1 cette fonctionnalité serait incroyable pour la productivité

+1

@publiclass1 @hevans90 , ... (insérer toutes les autres personnes qui ont commenté avec +1) ..., S'IL VOUS PLAÎT ne publiez pas de commentaires sur à quel point vous voulez cette fonctionnalité. C'est pour cela que GitHub a ajouté les réactions emoji. J'aime juste le commentaire d'origine. De cette façon, je peux recommencer à utiliser les notifications par e-mail à quoi elles étaient destinées (rester informé de l'évolution de ce problème, et non de quiconque dans le monde le souhaite également). Désolé tout le monde pour vous aussi spammer. J'espère sincèrement que plus de gens apprendront à arrêter les problèmes de +1 -ing.

+1

J'utilise PhpStorm mais je préfère utiliser VS Code pour tout. J'utilise actuellement autant de fenêtres VS Code que possible. Pouvez-vous éventuellement avoir ce système de coloration en option car je préfère / connais les couleurs PhpStorm. Pour référence:

Noir - À jour - Le fichier est inchangé.
Gris - Supprimé - Le fichier est programmé pour être supprimé du référentiel.
Bleu - Modifié - Le fichier a changé depuis la dernière synchronisation.
Vert - Ajouté - Le fichier est programmé pour être ajouté au référentiel.
Marron - Inconnu - Le fichier existe localement, mais n'est pas dans le référentiel et son ajout n'est pas planifié.

etc via https://www.jetbrains.com/help/phpstorm/2016.3/file-status-highlights.html . Vous êtes rock, merci.

et

  • les fichiers qui ont √©t√© fusionn√©s avec des conflits sont affich√©s en rouge,

c'est très pratique de distinguer les conflits des autres

+1 Avoir à basculer entre les vues Git <> Explorer est super improductif.

Id√©alement, il serait possible de voir √©galement l'ensemble de modifications en tant que groupe au-dessus o√Ļ nous avons des fichiers ouverts, ainsi qu'un arbre imbriqu√© de modifications visualis√© par couleur (comme indiqu√© par @abdonrd ci-dessus.)

Allez les gars, arrêtez avec le +1.

Merci de mettre un pouce bleu sur le premier post.

J'ai un cas d'utilisation et un argument intéressants pour créer une API générique qui permettrait au plugin de colorer des fichiers et des dossiers individuels :

Vieillissement des fichiers/dossiers similaire √† la mise sous tension du vieillissement de Trello - j'aimerais que les fichiers et dossiers qui n'ont pas √©t√© touch√©s depuis longtemps (√† en juger par l'historique de git) disparaissent, de sorte que le ¬ę¬†jeu de travail¬†¬Ľ soit plus distinct et plus facile √† trouver.

Pourquoi¬†: j'ai un grand d√©p√īt de petits projets (pensez √† un tas de scripts pour un rapport analytique) o√Ļ plus de 90¬†% du travail ne sera plus touch√© (mais je ne peux pas d√©placer d'anciens √©l√©ments dans un sous-dossier car cela casserait beaucoup de liens pointant vers repo).

S'il y avait un point de terminaison d'API pour colorer les éléments de l'arborescence, je pourrais écrire un plugin qui lit le journal git et colore chaque fichier/dossier selon un ensemble de règles.

Alors qu'en est-il, n'y a-t-il pas encore des API qui permettent de créer une extension pour cela, ou cela sera-t-il implémenté en tant que fonctionnalité intégrée ?

Une mise à jour pour ceci?

+1

+1

+1

Pouvez-vous, s'il vous pla√ģt, arr√™ter de +1 et de spammer nos bo√ģtes de r√©ception ???

Cela ne sert à rien du tout.

+1 à aucun spam xD

astuce¬†: filtrez les messages de github o√Ļ le corps est √©gal √†/correspond √†/lolwuts "+1"

vous ne pouvez pas arrêter ces gens.

@jmbelloteau comme @fredrikaverpil l'a dit plus t√īt dans les commentaires, les probl√®mes de VSCode sont tri√©s par le nombre de pouces jusqu'au commentaire d'origine. Donc commenter "+1" au lieu d'ajouter une r√©action au premier commentaire est en effet du spam, car ce n'est pas la bonne fa√ßon de fournir des commentaires et n'envoie que des e-mails inutiles √† tout le monde. Et contrairement √† l'ajout d'une r√©action, elle ne sera m√™me pas prise en compte.

+1

Je suis tellement habitu√© √† cela dans Webstorm aussi :D. Mais comme je peux le voir, cela sera probablement d√©velopp√© plus t√īt que tard. Voici une capture d'√©cran de Webstorm pour vous inspirer (suivant @abdonrd)¬†:

screen shot 2017-04-16 at 19 03 16

Ah, les fichiers non suivis sont également affichés en rouge !

+1

Je viens d'essayer le code VS pour la premi√®re fois aujourd'hui (provenant d'Atom) et l'une des premi√®res extensions que j'ai recherch√©es √©tait la mise en √©vidence de "git status" dans la vue de l'explorateur. L'onglet "contr√īle de source" en lui-m√™me est tr√®s agr√©able, mais la mise en surbrillance des dossiers/fichiers me permet de naviguer rapidement vers le composant sur lequel je travaille sans avoir √† toujours laisser mon arborescence de r√©pertoires √©tendue (tr√®s utile pour les bases de code FE qui ont tendance √† ont des structures plus profond√©ment imbriqu√©es).

idéalement, ce serait formidable si les couleurs pouvaient être modifiées individuellement.

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

+1

Je cherchais depuis un moment une bonne application pour me rappeler de boire de l'eau.
Ensuite, je me suis rendu compte que je suis abonné à ce fil.
Gardez les +1 √† venir les gars, ils ne sont plus inutiles ūüöį

@mmazzarolo
Pourquoi avez-vous besoin de rappel pour boire de l'eau? Ne suffit-il pas de boire quand on a soif ?

Quoi qu'il en soit, s'il vous pla√ģt arr√™tez +1-ing. Je suis s√Ľr que les d√©veloppeurs sont d√©j√† au courant et publieront des mises √† jour au fur et √† mesure.

@pohmelie c'est une alternative valable, merci !

+1

wtf a tort avec ces +1 personnes ?

Excellente idée, @davidhu2000 ! Ce serait bien de prendre également en charge les couleurs hexadécimales comme git.ignoredFileColor: '#333333' .

Il y a une belle liste des types et des couleurs que JetBrains utilise ici : https://www.jetbrains.com/help/idea/2017.1/file-status-highlights.html (vous pouvez inspecter le nom de la couleur pour obtenir l'hexadécimal).

+1 pour faire conna√ģtre √† quel point cette fonctionnalit√© est recherch√©e

La seule raison pour laquelle je n'utilise pas VS Code. Dommage :(

Quelqu'un sait-il o√Ļ dans la base de code on pourrait commencer √† impl√©menter cela? Je veux tenter le coup.

@admosity Quelqu'un a déjà soumis une pull request l'année dernière qui a été rejetée : https://github.com/Microsoft/vscode/pull/8462 .

2824 a √©t√© mentionn√© comme un bloqueur quelque part ci-dessus, qui a √©t√© fusionn√© il y a quelque temps. Je regarderais les changements l√†-bas pour m'assurer qu'il est mis en Ňďuvre comme le veut l'√©quipe VS.

@AndreasGassmann g√©nial ! Je vais jeter un Ňďil.

La dernière fonctionnalité clé m'empêche de passer à vs code

Lorsque cette fonctionnalité sera incorporée, je passerai à vscode

Je suis abonné à ce numéro car j'aimerais savoir quand des progrès sont faits.
Tout le monde sait à quel point cette fonctionnalité est recherchée et est actuellement la deuxième question la plus votée :).

Si vous voulez vraiment, vraiment cette fonctionnalité, votez simplement pour le premier commentaire et évitez d'ajouter des commentaires répétés .

Pour les personnes qui pensent que cette fonctionnalité est nécessaire pour passer à VS Code. Je peux dire que c'était la première fonctionnalité que j'ai manquée lors du passage d'Atom, mais IMO, c'est un petit prix à payer pour cet IDE génial.
De plus, la semaine derni√®re, j'ai d√Ľ travailler sur Atom et j'ai vraiment rat√© la vue git de VS Code.

@waderyan C'est un dealbreaker qui passe de l'atome.

Oui s'il vous pla√ģt!

+1

+1

+1

J'ai fait un hack tr√®s moche qui impl√©mente cette fonctionnalit√© en modifiant workbench.main.js et en injectant le CSS bas√© sur la sortie git status . Si cela ne vous d√©range pas de fouiller dans les fichiers internes de VS Code et que votre VS Code ex√©cute git status toutes les 5 secondes, jetez un Ňďil.

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

Mise √† jour 28.6.2017 : Correction d'un bug o√Ļ le plugin ne se chargeait pas lors de la r√©ouverture du projet.
Mise à jour 30.6.2017 : Ajout de la mise en évidence des répertoires parents des fichiers modifiés (comme le fait Atom).
Mise à jour 1.7.2017 : La correspondance des fichiers est désormais effectuée à l'aide du chemin complet du fichier ou du répertoire. Avant ce changement, le répertoire était mis en surbrillance s'il portait le même nom qu'un autre répertoire modifié.

Bonjour,
Je n'arrive pas à savoir si cette fonctionnalité est implémentée ou pas encore ?
Je n'ai trouvé aucun paramètre ni extension et comme cela a été ouvert il y a près de deux ans, je suis confus.

@sanjibukai Le probl√®me est toujours ouvert, il n'a donc pas encore √©t√© impl√©ment√©. Vous pouvez cependant utiliser le hack que @karabaja4 a cr√©√© dans le commentaire au-dessus du v√ītre.

Je suis nouveau ici, mais faut-il vraiment près de deux ans pour ajouter cette fonctionnalité évidente ?
√Čtonnamment, je n'ai jamais entendu parler de vscode jusqu'√† r√©cemment, mais quand j'en ai entendu parler, la principale caract√©ristique qui a √©t√© pr√©conis√©e est pr√©cis√©ment √† quel point vscode est une bonne int√©gration de git. Et effectivement c'est bon.
Quel dommage que cette fonctionnalité manque encore..
N√©anmoins, gardez le bon travail de l'√©quipe vscode ūüĎć

Impossible de rester concentré sans cette fonctionnalité. Chaque fois que je dois me rappeler quel fichier j'édite.

+1

@ karabaja4 pourquoi ne pas faire de relations publiques avec votre hack et obtenir des commentaires sur la fa√ßon de le mettre en Ňďuvre correctement¬†?

@saada Je le ferais si je pensais que l'un de ces codes pourrait être intégré à VS Code. L'exécution d'un processus git status arrière-plan n'est certainement pas une façon saine d'implémenter cette fonctionnalité. Tout code approprié qui implémente cela doit être écrit à partir de zéro et implémenté correctement dans le cadre source de VS Code. C'est beaucoup de travail et malheureusement pour le moment je n'ai pas assez de temps disponible. Désolé :(

S'accumuler ne va pas aider les choses lorsque leur m√©trique d√©clar√©e est d√©j√† le nombre de +1 que le message d'origine obtient, pas dans les r√©ponses. De plus, √©tant donn√© qu'il s'agit d'un outil pour les d√©veloppeurs, je suis un peu √©tonn√© de voir combien de droits et de ne pas comprendre le processus open source qui se d√©roule ici. La demande de fonctionnalit√© est ici en tant que probl√®me ouvert. Vous pouvez lui attribuer +1 sur le message et le faire vous-m√™me (vraisemblablement en travaillant avec les responsables pour vous assurer que ce n'est pas en vain) et demander une fusion ou simplement en rester l√†. Si c'est une fonctionnalit√© vitale pour vous, alors utilisez Atom. Au moment o√Ļ j'√©cris ces lignes, il y a plus de 4000 probl√®mes ouverts. Vous devrez faire preuve de patience.

(ou utilisez @karabaja4 hack en attendant - merci pour votre travail !)

+1
Faire cela parce qu'il suffit d'écouter parler devchat et les problèmes avec plus de commentaires

@karabaja4 excellent travail. Une autre approche : que diriez-vous d'exécuter git status à l'initialisation, puis de mettre à jour chaque fois que l'événement onFileSave est déclenché ? serait-ce plus efficace ?

peut-être pourrions-nous configurer la façon dont nous actualisons le statut git.

+1 cela serait très utile si ajouté

@Kaijun Je ne sais pas comment mettre en Ňďuvre cela. D'o√Ļ viendrait l'√©v√©nement onFileSave¬†?

S'il provient du code lors de l'enregistrement du document (en supposant que je sache comment le joindre), les fichiers modifiés en dehors du code seraient ignorés, tout comme les modifications telles que le déplacement et la copie de fichiers.

S'il provient d'une logique de surveillance de dossier qui est implémentée sur l'arborescence des solutions, cela devrait être fait de manière récursive pour l'ensemble de l'arborescence. Je ne sais pas si ça vaut le coup en termes de performances.

@ karabaja4 Je pense que le code d√©tecte √©galement les changements ext√©rieurs. Donc, s'accrocher √† un tel "√©v√©nement" avec peut-√™tre un syst√®me anti-rebond afin que plusieurs modifications de fichiers dans le m√™me intervalle ne d√©clenchent pas trop de v√©rifications de statut git. Cela pourrait fonctionner !. Peut-√™tre que quelqu'un qui conna√ģt la pi√®ce fs peut intervenir¬†?

Cela ne devrait vraiment pas être en retard. Il y a une valeur très réelle à ajouter cette fonctionnalité apparemment petite. Le bonheur des développeurs va de pair. Décevant de voir que ce problème a des milliers de +1 et est ignoré depuis 2015.

@kamok c'est vrai ! Bien qu'Atom soit lent, j'avais une autre option... Je suis retourn√© √† WebStorm, qui est invaincu par la fa√ßon dont il s'int√®gre √† Git ainsi que d'autres fonctionnalit√©s pour lesquelles vous devez installer des extensions sur vscode, et il parvient toujours √† √™tre si rapide et ressemble √† un √©diteur l√©ger plut√īt qu'√† un IDE, en termes de vitesse. Cette fonctionnalit√© seule (statut Git dans l'explorateur de fichiers) ne serait toujours pas suffisante pour garder les utilisateurs de vscode. Ce ne serait qu'une goutte dans le seau. C'est la fonctionnalit√© qui me manque le moins, venant de WebStorm.
Je suggère que l'équipe vscode regarde comment les gars de JetBrains le font.
Je suis désolé, mais j'ai essayé... J'ai lutté avec vscode pendant des mois maintenant, j'ai attendu mise à jour après mise à jour, mais je me suis toujours retrouvé à fermer constamment vscode et à rouvrir le projet dans WebStorm pour : Statut Git dans l'explorateur arbre, caches, vue dossier/arborescence pour les modifications locales, comparaison des branches, clic droit > comparer avec le presse-papiers... Et ce ne sont que des idées. L'intégration de Vscode Git a encore un long chemin à parcourir s'ils veulent vraiment aider les développeurs.

_Envoyé depuis mon Samsung SM-G950F en utilisant FastHub _

@MrCroft Je vous suggère de contacter directement l'équipe si vous êtes tellement préoccupé par leur méthodologie de travail, sinon vous attribuez +1 au problème avec un pouce levé et changez d'éditeur si cela vous dérange autant.

@cucumbur je l'ai d√©j√† fait (pass√© de vscode). Je ne fais que dire mon chagrin, car j'ai vraiment aim√© la sensation de vscode. J'aurais aim√© qu'il ait une bonne int√©gration Git pour pouvoir continuer √† l'utiliser. Je suis s√Ľr que beaucoup de gens ressentent la m√™me chose.
Je vais quand m√™me garder un Ňďil dessus. Peut-√™tre, qui sait, dans un "avenir pas tr√®s lointain" ce serait fait... A part le vscode, je suis en fait un grand fan de Microsoft... Logiciel et mat√©riel, ils construisent des trucs de tr√®s haute qualit√© 9 fois sur 10 . J'esp√®re juste que vscode deviendra l'un des 9.

_Envoyé depuis mon Samsung SM-G950F en utilisant FastHub _

@kamok Chaque nouveau problème entre dans le backlog et y reste jusqu'à ce qu'il soit résolu. Je ne pense pas que cette fonctionnalité soit ignorée du tout. cela nécessite juste plus de changements que vous ne le pensez. Pour autant que je sache, ils veulent en faire une partie de l'API des extensions, et actuellement l'arborescence des fichiers manque de nombreuses fonctionnalités pour que cela se produise.

Si vous triez les probl√®mes par pouce lev√©, vous verrez que ce probl√®me est le deuxi√®me le plus populaire, le premier est en cours d'√©laboration et presque termin√©. Je suis presque s√Ľr qu'ils commenceront √† travailler l√†-dessus d√®s que l'autre sera termin√©.

Une mise à jour occasionnelle sur ce fil serait bien cependant.

Basculé depuis atom mais sur un grand projet sans avoir mis en évidence les fichiers mis à jour, il est difficile de travailler avec.
Revenir à Atom jusqu'à ce que cette fonctionnalité soit disponible

Peut-√™tre qu'il vaut la peine de mentionner qu'une solution alternative/int√©rimaire qui fonctionnerait pour moi... consiste √† dupliquer l'arborescence dans la vue "Ouvrir les √©diteurs". En r√®gle g√©n√©rale, la vue me montre des fichiers "mis √† jour", mais ce n'est qu'un vidage de noms de fichiers si difficile √† travailler, par opposition √† s'il √©tait clair o√Ļ dans le projet ces fichiers se trouvent.

Des mises à jour à ce sujet ?

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

Je suis masochiste mon propre commentaire.

Je continue d'essayer VSCode mais comme cette fonctionnalité fait défaut, cela m'empêche de basculer. Je n'avais pas réalisé à quel point je comptais sur cette fonctionnalité dans Atom jusqu'à ce que j'essaie de changer.

En attendant que cela passe au code VS d'atom, j'esp√®re qu'il sera bient√īt mis en Ňďuvre.

+1

deux ans ont pass√©„Äā„Äā„Äā

et étonnamment, votre commentaire n'a pas fini par changer cela. Ceux d'entre nous qui se soucient du développement et des contributions potentielles s'abonnent à ces fils de discussion, votre commentaire n'a servi à rien et il envoie un e-mail inutile à 99 personnes

Hé, vous n'obtenez aucun résultat à moins d'essayer, n'est-ce pas ?

Cela me manquait beaucoup au d√©part, et bien qu'il serait tr√®s pratique de l'avoir, le 'diff explorer' (troisi√®me ic√īne dans le menu vertical) est vraiment puissant et c'est tr√®s utile

+1
Ce serait génial si cela implémentait wooow...!

J'ai √©crit une t√Ęche gulp qui devrait simplifier l'installation du hack (VS Code 1.15 uniquement).

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

PS Pas encore testé sur toutes les plateformes, j'apprécierais que quelqu'un l'essaye sur OSX.

@ karabaja4 Il ne semble pas que votre 'hack' soit si compliqu√© √† impl√©menter dans vscode lui-m√™me. Comme il semble que les d√©veloppeurs vscode ne r√©solvent pas ce probl√®me de sit√īt, vous pourriez peut-√™tre cr√©er une pull request ?

@karabaja4 Merci pour ça ! Travailler pour moi sur macOS Sierra, VSCode 1.15.1.

@karabaja4 Merci ! Travailler ici sur Fedora 26, VSCode 1.15.0. Celui-là seul a rendu le passage d'Atom tellement plus pratique.

@karabaja4 +1 Merci !! Travailler pour moi sur Ubuntu 14.04 64, VSCode 1.15.1 (installation manuelle)

+1

@ karabaja4 +1 C'est génial.

+1

@matti plus un

_Envoyé depuis mon HTC MSM8996 pour arm64 en utilisant FastHub _

@ibrokemypie moins deux

Envoyé depuis mon HTC MKB826262 pour arm32 en utilisant Lolbug

Des nouvelles de cette fonctionnalité ?

+1

+1

+1

@karabaja4 MERCI mec =D <3

+1

Wow, cela aurait d√Ľ √™tre mis en Ňďuvre il y a deux ans

@eosrei +1

+1

+1
Faisons face à la réalité ; J'adore VSCode, mais l'onglet Git est vraiment nul

@karabaja4 Salut, la 1.16 vient de sortir, vas-tu porter ton hack sur cette version ? Merci.

EDIT : Fonctionne avec 1.16, mais pas lors de l'utilisation d'espaces de travail multi-racines.

@ karabaja4

@karabaja4 vient de faire ma journée. Merci mec!

+1

+1

Un commentaire +1 devrait être une interdiction automatique des problèmes GitHub...

Ce serait mieux si GitHub se contentait d'analyser les messages +1 et de les remplacer automatiquement par une réaction emoji de pouce levé au message d'origine.

@karabaja4 votre hack fonctionne sur OSX 10.12.6 - génial ! Merci.

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

La seule chose est que je reçois maintenant un message d'avertissement au démarrage. Heureusement, ce n'est qu'un avertissement.

VSCode Version 1.16.0

+1

Y a-t-il une raison pour laquelle cela n'est pas encore implémenté ou existe-t-il un calendrier pour l'ajout de cette fonctionnalité ?

Hier, je suis retourné sur Atom pendant une heure pour utiliser leur dernière mise à jour ide et je pensais que ma vie était si facile avec des fichiers colorés dans l'arborescence des fichiers.

Edit : Je viens de trouver une solution de contournement. L'ajout d'une ligne à l'un des fichiers de code vs (< 1min d'effort) fonctionne à merveille ! https://github.com/karabaja4/vscode-explorer-git-status

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

Avez-vous déjà vu que vous pouviez utiliser la réaction emoji au lieu de poster +1 ?

Chaque fois que nous publions des commentaires sur github, tous les abonnés du sujet reçoivent des notifications et certains utilisateurs reçoivent également des e-mails. C'est un peu frustré de lire un email écrit : +1 et vous pouvez voir sur ces commentaires, il y a beaucoup de :-1:.

La communauté apprécie si nous commençons tous à utiliser les réactions à la place :
https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments

Je m'excuse pour toute infraction avec cette information et pour les autres recevant cette notification.

J'avais lu dans d'autres fils de discussion que Microsoft évaluait la priorité d'une fonctionnalité par le nombre de commentaires +1. Je m'excuse si je me suis trompé et n'est en aucun cas le classement d'une fonctionnalité. J'ai supprimé mon commentaire. Quoi qu'il en soit, qu'est-ce que c'est que l'attitude agressive frère? Tu aurais pu souligner la même chose avec un meilleur ton @leocaseiro

À votre santé.

Salut @aecorredor , je m'excuse si cela
Je ne suis pas anglophone et peut-√™tre que l'une de mes expressions traduites sonnait mal. S'il vous pla√ģt, aidez-moi √† am√©liorer la description de ce commentaire. Dois-je remplacer le mot ennuyeux ? inutile? Merci.

PS : Je suis content que vous ayez édité le monde que j'ai lu sur mon e-mail, car j'ai peut-être l'air grossier, mais je n'ai jamais eu l'intention d'offenser qui que ce soit.


Mise à jour : j'ai remplacé mon commentaire précédent, veuillez me faire savoir si cela sonne mieux. Merci

Salut @leocaseiro ,

Désolé d'avoir écrit ce gros mot en premier lieu. en fait j'ai réalisé
qu'une barrière linguistique était probablement ce qui causait la confusion. Mais
oui, je remplacerais ces deux mots par quelque chose de plus du genre :
"S'il vous pla√ģt, nous essayons tous d'am√©liorer l'exp√©rience globale de github pour
problèmes ouverts/demandes de fonctionnalités, et ce serait bien si les gens commençaient à utiliser
réactions emoji au lieu de commentaires comme "+1", qui ne font que créer
surcharge inutile dans le fil et déclencher des e-mails qui ne sont pas vraiment
contribuer de manière significative. Veuillez vous référer à ce lien pour voir comment
Les réactions emoji fonctionnent : { Lien ici }

Bravo, et pas de rancune.

Meilleurs.

Le lun 18 sept. 2017 √† 23h44, Leo Caseiro [email protected]
a écrit:

Salut @aecorredor https://github.com/aecorredor , je m'excuse si sonné
Impoli.
Je ne suis pas anglophone et peut-être l'un de mes traducteurs
les expressions sonnaient mal. S'il vous pla√ģt, aidez-moi √† am√©liorer la description pour
ce commentaire. Dois-je remplacer le mot ennuyeux ? inutile? Merci.

PS : je suis content que vous ayez édité le monde que j'ai lu sur mon e-mail, car je peux
ai semblé grossier, mais je n'ai jamais eu l'intention d'offenser qui que ce soit.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/Microsoft/vscode/issues/178#issuecomment-330420547 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AIsVa9fgWXPMFBgkZdHjQHKhUEDJb8Bmks5sjziWgaJpZM4GlYyH
.

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

Utilisez une réaction à la place d'un commentaire "+1".

+1

J'esp√©rais vraiment que le nombre de +1 diminuerait apr√®s les commentaires pr√©c√©dents, mais soudain, un autre +1 est apparu ūüėĀ .

C'est dommage, car les programmeurs reprochent souvent aux utilisateurs de ne pas lire les messages d'erreur, mais ne peuvent pas lire certains commentaires ou instructions.

Peut-être qu'il vaudrait la peine de mettre quelque chose sur README.md pour demander aux utilisateurs d'utiliser des réactions au lieu de commenter +1 ? Peut-être que sur CONTRIBUTING.md c'est un peu caché.

Je ne sais pas, je pense que je vais juste me désinscrire et attendre les notes de version quand il sera prêt.

J'ai créé un Gist qui s'occupe de cela. Le correctif de @ karabaja4 ne grise pas correctement les fichiers/dossiers ignorés (voir ses problèmes). Il y a un PR de @dseipp qui n'a jamais été fusionné. Il y avait toujours quelque chose qui n'allait pas avec ses relations publiques (je pense qu'il manquait le support mis en scène ?), alors je l'ai corrigé.

Donc, si vous souhaitez que cela fonctionne beaucoup mieux, consultez mon résumé : https://gist.github.com/WadeShuler/1637073371ad126779076344c34278f3

@ikatyang : désolé, cela signifie-t-il que cette fonctionnalité sera introduite en octobre (2017)..?

@nkkollaw le lien provient de ce commentaire : https://github.com/Microsoft/vscode/issues/34160#issuecomment -331066864

Le commentaire demandait simplement de discuter des choses liées à ce problème ici, et non dans le "Plan d'itération" (et demandait de les discuter en anglais).

Ah, j'ai compris @tiangolo , merci.

J'essaierai de supporter Atom jusqu'à ce qu'il y ait une API pour implémenter cette fonctionnalité (désolé, je ne suis pas assez bon pour aider du tout).

Je travaille à faire la mise à jour au sein du projet lui-même.
Pour l'instant, j'ai fait une preuve de concept qui fonctionne mais je ne passe pas le tslint, car j'ai encore besoin de comprendre les calques afin de tout remettre au bon endroit.
Je vais mettre une mise à jour ici, et si quelqu'un veut m'aider, je mettrai le lien vers ma demande d'extraction plus tard, donc vous êtes les bienvenus pour aider.

Prévu en octobre 2017 itération !! ??

Nous en avons une première version. Que tout le monde soit assuré que cela viendra en octobre.

oct-09-2017 18-09-19

Un peu plus d'informations :

  • Les couleurs seront d√©finies par th√®mes, ce qui signifie qu'elles peuvent √™tre adapt√©es √† vos go√Ľts
  • Il y aura un param√®tre pour activer/d√©sactiver ce
  • Ce n'est pas exclusif au contr√īle de version. Nous cherchons √©galement √† mettre en √©vidence les erreurs/avertissements dans l'explorateur de fichiers (voir #782) et nous pensons exposer cela aux auteurs d'extensions.

Questions ouvertes:

  • Est-ce que l'utilisation d'une seule couleur suffit ? Devrait-il y avoir √©galement un indice textuel et/ou ic√īne¬†?
  • Quel statut d'enfant un parent doit-il choisir ? Cela devrait-il passer par l'importance? C'est facile avec les erreurs et les avertissements, mais qu'est-ce qui est le plus important, un fichier modifi√©, non suivi ou ignor√©¬†?
  • Devrions-nous afficher ces d√©corations de fichiers √©galement dans le compartiment ¬ę¬†Open Editors¬†¬Ľ et/ou le s√©lecteur de fichiers, etc.¬†?

Je garderai ce problème à jour pendant que des choses se passent. Comme toujours, utilisez des émotions au lieu de commentaires "+1". Merci et bon codage !

Personnellement, ce que je vois sur l'image ci-dessus est suffisant. Ça a l'air super et merci !

Il semble manquer les fichiers ignorés par .gitignore en gris foncé ?

Vous ne changez pas la couleur (gris) d'un dossier parent pour juste un fichier ignor√© √† l'int√©rieur. Vous ne le grisez que SI le dossier lui-m√™me est ignor√©. S'il vous pla√ģt voir mon commentaire / corriger quelques commentaires. Il fait que Git vide les statuts et d√©tecte s'il s'agit d'un r√©pertoire ou d'un fichier. Le simple fait d'ajouter des classes aux fichiers/dossiers de l'arborescence de fichiers fonctionnerait... Comme "git-status-modified" ou "git-status-added". Ensuite, les th√®mes peuvent op√©rer leur magie.

Ce serait bien si vous pouviez nous laisser tirer ce sur quoi vous travaillez, afin que nous puissions jouer avec et créer des relations publiques. Honnêtement, si c'est foiré, les gens cesseront probablement d'utiliser Code si une solution viable ne peut pas être trouvée dans un délai raisonnable. De nombreuses personnes (y compris moi-même) ont quitté Atom pour des problèmes similaires.

Je pense aussi que s'il y a des erreurs, utilisez peut-être un point avant ou après le nom du fichier dans l'arborescence. Ce serait discret, laisserait les thèmes les styliser et n'interférerait pas avec la mise en évidence des couleurs Git.

Oui, cela DOIT √™tre ouvert aux d√©veloppeurs d'extensions¬†! Cela aurait d√©j√† d√Ľ √™tre fait. Pourquoi ne voudrions-nous pas contr√īler l'arborescence des fichiers pour cr√©er des extensions int√©ressantes ou r√©parer des choses que vous n'avez pas faites¬†?

Il semble manquer les fichiers ignorés par .gitignore en gris foncé ?

Bien s√Ľr, c'est un travail en cours et les choses arrivent une √† la fois. Les fichiers ignor√©s viendront, √©galement en octobre.

Ce serait bien si vous pouviez nous laisser tirer ce sur quoi vous travaillez, afin que nous puissions jouer avec et créer des relations publiques.

Bien s√Ľr, tout est dans la branche joh/feco . Il existe un nouveau service de d√©coration qui utilise des fournisseurs pour les donn√©es r√©elles. Du c√īt√© consommateur se trouve l'√©tiquette de fichier que nous utilisons pour le rendu des noms de fichiers

Vous ne changez pas la couleur (gris) d'un dossier parent pour juste un fichier ignor√© √† l'int√©rieur. Vous ne le grisez que SI le dossier lui-m√™me est ignor√©. S'il vous pla√ģt voir mon commentaire / corriger quelques commentaires.

Je pense que "les fichiers ignorés et leurs enfants (le cas échéant) sont grisés" est assez clair.

@nkkollaw De quoi parles-tu ?!

Dans @jrieken a dit :

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

Il a indiqué un fichier ignoré pouvant influencer le statut des dossiers parents, ce qu'il ne devrait pas faire !

Votre message passif agressif ne fait qu'encombrer ce fil de messages inutiles...

@WadeShuler : Je n'ai aucune idée de ce dont _vous_ parlez.

Je viens de souligner que les fichiers ignorés et leurs enfants doivent être grisés, et il est assez clair que cette définition ne demande pas que les parents des fichiers ignorés soient grisés.

Pour ce qui est de:

Votre message passif agressif ne fait qu'encombrer ce fil de messages inutiles...

Je n'ai aucune idée de la façon dont mon message était passif-agressif - je suppose que vous ne savez pas ce que cela signifie - mais c'est vous qui obstruez ce fil, puisque vous êtes le seul à avoir commenté après mon message.

Bizarre.

wow.. bonne idée ! je l'aime bien!

Je voudrais avoir le xcode comme un indice textuel à caractère unique dans une colonne de droite. Rend les fichiers faciles à filtrer/suivre visuellement.

@nkkollaw j'ai dit:

Vous ne changez pas la couleur (gris) d'un dossier parent pour juste un fichier ignoré à l'intérieur. Vous ne le grisez que SI le dossier lui-même est ignoré.

Clairement, je parle des dossiers parents, pas des enfants. Tiens, je t'ai fait un dessin :

vscode-git-status-tree-explain

Voici le .gitignore dans le répertoire parent, web pour référence :

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

Mon message √©tait une r√©ponse √† la r√©ponse de @jrieken du WIP, ici , o√Ļ il dit :

Quel statut d'enfant un parent doit-il choisir ? Cela devrait-il passer par l'importance? C'est facile avec les erreurs et les avertissements, mais qu'est-ce qui est le plus important, un fichier modifié, non suivi ou ignoré ?

Indiquant qu'un parent d'un fichier/dossier "ignor√©" peut avoir un statut, ce qui n'est pas le cas. D'o√Ļ ma r√©ponse. Vous confondez ce que vous voyez visuellement par rapport √† ce que Git utilise r√©ellement pour sa liste d'ignor√©s

‚ěú  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 signifie qu'il est d√©fini dans .gitignore avec une r√®gle sp√©ciale, donc pourquoi il est non seulement backend/web/assets/ et il est sp√©cifiquement les dirs d'actifs d√©sign√©s au hasard. Vous ne sp√©cifiez pas chaque fichier ignor√©, lorsque vous traitez avec un r√©pertoire o√Ļ son contenu est ignor√©. Tels que les r√©pertoires vendor ou node_modules . Ils n'ont qu'une seule entr√©e dans l'entr√©e ignor√©e git status .

Dans l'arborescence des fichiers, vous devez ajouter une classe de git-status-ignored à TOUS les éléments (fichiers et dossiers) qui commencent par backend/web/assets/6f57f06b/ .

Le CSS pour faire correspondre le dossier de l'arborescence de fichiers backend/web/assets/6f57f06b/ est comme ceci (prend actuellement 2 règles !) :

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

ET

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

Remarque¬†: Dans la premi√®re r√®gle, nous faisons correspondre le titre avec un signe = , donc exactement¬†! Dans la 2√®me r√®gle, nous faisons correspondre tous les titres avec ^= , donc le d√©but de la cha√ģne, correspondant √† tout ce qui est plus profond que cela (tous les enfants).

Pour faire correspondre un répertoire prend 2 règles CSS. Donc, je pense qu'en faisant cela, nous devrions aller de l'avant et faire le title sur l'élément HTML pour les répertoires, pour inclure une barre oblique finale. Vous pouvez voir de quoi je parle dans cette capture d'écran :

vsc-dir-trailing-slash

Oui, votre commentaire était passif agressif, car vous étiez grossier/snark/merdique sans vraiment dire les mots. En plus tu t'es trompé. Personne n'a rien dit sur les enfants, et ce n'est même pas de cela dont nous parlions.


@jrieken
La façon dont ma configuration d'Atom fonctionne : "édité" a la priorité sur "ajouté". La suppression d'un fichier n'affiche aucun état. Il n'y a pas de statut pour "mis en scène". Je pense que les autres devraient vérifier leur configuration Atom et voir si cela est également vrai pour eux, et que ce n'est pas seulement ma configuration. Il serait bon d'ajouter du code pour chaque situation et de laisser l'utilisateur le modifier pour qu'il fonctionne comme il le souhaite.

Peut-être ajouter plusieurs classes, de sorte que les répertoires parents tout en haut de l'arborescence auraient "git-status-added" et "git status-modified". Peut-être même ajouter "git-status-deleted" si quelque chose a été supprimé en dessous.

Ensuite, utilisez simplement css pour les faire correspondre. Si vous voulez une couleur différente pour .git-status-added.git-status-modified , vous pouvez faire une police orange avec un soulignement vert (orange pour modifié, vert pour ajouté). S'il n'y avait que la classe .git-status-added , alors rendez la police verte.

Cela n'aurait pas vraiment d'importance une fois que vous leur ajouteriez des classes, tout le monde peut cr√©er du CSS comme il le souhaite. Vous voudriez cependant qu'un "assez bon" par d√©faut sorte de la bo√ģte.

Je tirerai cette branche quand j'aurai un peu de temps, et vérifierai.


Comment gérer les erreurs Lint ET le statut git ?

Atom met une ligne ondulée rouge sous le nom du fichier, comme vous pouvez le voir ici :

image

Je pense que nous devrions ajouter une classe telle que lint-error au même élément que le statut git, que nous (et les thèmes) pouvons remplacer via nos propres feuilles de style.

Donc, le div pour le même élément dans l'arborescence de fichiers que j'ai utilisé comme exemple ci-dessus (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>

Cela ressemblerait à ceci, lorsque nous appliquons à la fois un statut git de git-status-edited et lint-error :

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

Ensuite, nous pourrions faire correspondre via 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;
}

Vous avez un Slack ? Il y a beaucoup de fichiers √©dit√©s dans le commit. Je cherche exactement o√Ļ vous appliquez la couleur d'√©tat git √† l'arborescence des fichiers. C'est dans /extensions/git/src/repository.ts ?

Merci à tous et merci d'avoir clarifié les règles des modifications, des fichiers non suivis et ignorés. Les initiés de demain seront livrés avec une première version de cela.

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

Un certain nombre de choses

  • Par d√©faut, il y a une combinaison de couleur et de bagde.

    • activer/d√©sactiver les ic√īnes avec¬†: "explorer.decorations.badges": true|false

    • activer/d√©sactiver les couleurs avec "explorer.decorations.colors": true|false

  • Les couleurs s'affichent dans l'arborescence des fichiers, dans la section des √©diteurs ouverts et dans la vue SCM
  • Il y a trois couleurs pour commencer. Vous pouvez les personnaliser dans le param√®tre workbench.colorCustomizations . Les couleurs sont gitDecoration.modifiedResourceForeground ,
    gitDecoration.deletedResourceForeground ,
    gitDecoration.untrackedResourceForeground ,
    gitDecoration.ignoredResourceForeground , et
    gitDecoration.conflictingResourceForeground
  • Notez que les noms des param√®tres, etc. vont probablement changer, de nouveaux param√®tres peuvent √™tre ajout√©s, d'autres param√®tres peuvent √™tre supprim√©s √† nouveau.

Pour info - édité pour refléter les modifications apportées après la publication initiale

Je pense qu'il vaut mieux ne pas appliquer les ic√īnes de droite aux r√©pertoires parents. Il peut y avoir au moins une option.

Cela semble avoir √©t√© mis √† jour dans la version d'initi√© avec scm.fileDecorations.useIcons et scm.fileDecorations.useColors remplac√©s par scm.fileDecorations.enabled qui donne √† la fois les ic√īnes et les couleurs.

Je voudrais n'avoir que les couleurs mais pas les ic√īnes. IE le "vieux" comportement de scm.fileDecorations.useIcons : false et scm.fileDecorations.useColors : true

J'ai essayé d'expérimenter avec explorer.decorations.badges et explorer.decorations.colors mais ils semblent n'avoir aucun effet.

√ČDITER:
J'utilise la version 1.18 initié, Commit f1ee80be081b0d... sur Windows 10
(Ce serait bien si le texte dans la bo√ģte de dialogue √† propos de serait s√©lectionnable pour que vous puissiez le copier)

Merci d'avoir préparé ça

J'ai eu quelques réflexions :

  • il semble que la couleur s√©lectionn√©e soit toujours l'ancien gris au lieu de la couleur d'√©tat
  • d'accord avec l'option d'avoir des ic√īnes ou non (par @FredrikFolkesson )
  • avec les ic√īnes montrant, si la couleur modifi√©e/mise √† jour est claire, le 'M' ou 'U' doit √™tre sombre (ou vice versa) donc le contraste est l√† et c'est plus facile √† lire.

Au plaisir de ne pas avoir à mettre à jour le fichier main.js à chaque build pour obtenir les couleurs !!!

Problème mineur (j'utilise les derniers initiés au 16 octobre) à signaler,

Un autre probl√®me que j'aimerais aborder est le m√™me codage couleur non seulement pour l'arborescence du projet, mais √©galement pour la section des √©diteurs ouverts. Actuellement, il n'y a aucun moyen de voir dans la section des √©diteurs ouverts quels fichiers ont √©t√© modifi√©s et lesquels ne le sont pas. La possibilit√© de d√©terminer rapidement quels √©diteurs sont pour les fichiers modifi√©s est TR√ąS pratique, de sorte que l'on peut sauter rapidement entre les fichiers qu'il modifie et qu'il n'est pas n√©cessaire d'essayer de se souvenir des noms des fichiers actuellement modifi√©s.

Ce serait une excellente fonctionnalité. Nouveau sur VSC d'Atom et ça me manque beaucoup.

Je viens juste de déménager d'Atom et il manque également cette fonctionnalité. Quand la sortie de cette fonctionnalité est-elle prévue ?

De même, c'est surtout important car les fichiers ignorés par git sont trop importants dans la liste et ils se mélangent avec tout...

Salut, je pense que nous avons également besoin d'une clé de couleur pour changer la couleur de premier plan des badges (#36246)

image

Merci à tous pour les commentaires continus. J'ai mis à jour mon commentaire de synthèse initial pour refléter les changements récents. J'ai également veillé à ce que les modifications apportées aux paramètres soient reflétées sans rechargement et que la couleur d'état l'emporte sur la couleur de sélection.

Par défaut, nous utilisons toujours la couleur et un badge, principalement pour deux raisons : tout le monde ne sait pas immédiatement ce que signifie la couleur et le fait d'avoir le badge (avec son infobulle) peut rendre cela auto-explicatif. Deuxièmement, il y a des gens, en fait comme moi, qui ont des difficultés à distinguer ces couleurs et le badge est destiné à rendre cela un peu plus accessible.

@jrieken Pouvez-vous me dire si les classes CSS sont appliquées aux éléments de l'explorateur d'arborescence de fichiers de gauche ? Cela donnerait la meilleure extensibilité et permettrait aux développeurs de thèmes, et à nous personnellement, de personnaliser et de remplacer facilement les couleurs.

Par exemple¬†: lorsque vos nouveaux correctifs de code marquent un fichier ou un dossier comme ajout√©, il doit ajouter une classe telle que git-status-added . Ensuite, nous pouvons cibler si via nos feuilles de style pour personnaliser les couleurs et ne pas √™tre coinc√© avec ce que vous nous donnez hors de la bo√ģte.

@WadeShuler Nos personnalisations de thème/couleur ne fonctionnent pas directement avec css mais avec quelque chose que nous appelons couleurs de thème . C'est une indirection, donnant des noms à certaines choses comme editorLineNumber.foreground est le nom de la couleur de premier plan pour les numéros de ligne. Les thèmes attribuent des couleurs à ces noms et l'éditeur récupère ces valeurs lors du rendu. Consultez ceci pour plus d'informations à ce sujet : https://code.visualstudio.com/docs/getstarted/theme-color-reference

Avec les prochains initi√©s, probablement demain le 19, il y aura un rendu sp√©cial pour les fichiers ignor√©s ( git.color.ignored ) et les couleurs/badges appara√ģtront dans la section "Ouvrir les √©diteurs". J'ai mis √† jour https://github.com/Microsoft/vscode/issues/178#issuecomment -335511695 en cons√©quence.

@jrieken Génial ! Qu'en est-il d'une clé de couleur pour le premier plan des badges git ?
https://github.com/Microsoft/vscode/issues/178#issuecomment-336904514

Très bon travail! C'est formidable de voir cette fonctionnalité arriver sur vscode.


Dans l'implémentation actuelle, les fichiers modifiés dans un sous-module ne sont pas encore marqués correctement comme étant modifiés.

Dans l'exemple suivant :

Le référentiel principal comprend un sous-module dans src/components/ . Plusieurs fichiers ont été modifiés dans le sous-module. vscode signale correctement que src/components/ est modifié mais il n'indique pas quelles modifications ont été apportées dans le sous-module.

vscode

Atom identifie correctement les fichiers modifiés :
atom

Ce problème est probablement lié à https://github.com/Microsoft/vscode/issues/7829

@jrieken Génial ! Qu'en est-il d'une clé de couleur pour le premier plan des badges git ?

@equinusocio Pas de soucis, cela arrivera mais nécessite une réflexion. c'est prévu pour octobre

@jrieken Merci !. J'ai rat√© quelque chose. Les ic√īnes de dossier obtiennent √©galement la couleur modifi√©e/ajout√©e¬†? Existe-t-il une nouvelle cl√© √† ajouter au th√®me d'ic√īnes pour d√©finir une ic√īne diff√©rente pour les dossiers lorsque git est √©dit√©/modifi√©¬†?

@jrieken - Problèmes dans 1.18. Je tiens à vous remercier pour votre travail jusqu'à présent. Je viens de tester les Insiders v1.18. J'ai parcouru le fil ci-dessus, alors excusez-moi si vous avez déjà quelque chose en préparation pour 1.19 pour répondre à ce que je mentionne ci-dessous.

1) Le statut "ajouté" dans l'arborescence des fichiers ressemble à "mis à jour et non fusionné" avec le badge "U". Les fichiers ajoutés doivent avoir un badge "A".

2) Il n'y a pas d'option de couleur pour git.color.added

3) Il n'y a pas d'option de couleur pour git.color.ignored .

4) (Glitch) Il traite les fichiers "ajout√©s" comme "non suivis". J'ai inspect√© un fichier "ajout√©", et il semble que dans le code HTML, il pense qu'il n'est pas suivi. (le titre span dit "non suivi" et la classe est monaco-decorations-style-32 , l'ic√īne "U"). Cela est √©vident lorsque vous modifiez la couleur de workbench.colorCustomizations pour git.color.untracked , car il contr√īle les fichiers "ajout√©s" suppos√©s.

5) Prise en charge du statut "R", pour "renommé" ou déplacé, ajoutez un badge "R" et ajoutez le paramètre git.color.renamed .

Merci, j'ai h√Ęte d'essayer la 1.19 ūüĎć

@danjjl Il y a un PR en attente pour # 7829 Avec cela appliqué, les sous-modules git obtiennent la coloration.

Il y a un problème potentiel, en ce que si le sous-module est modifié, je ne sais pas s'il (le répertoire qui est la racine du sous-module) sera traité comme la couleur du statut du répertoire dans le référentiel git principal, ou un autre couleur basée sur les fichiers contenus.

C'est-√†-dire que je ne sais pas si la couleur du r√©pertoire du sous-module sera bas√©e sur ¬ę¬†git status¬†¬Ľ dans le r√©pertoire parent ou dans le sous-module. Cela n'a peut-√™tre pas d'importance de toute fa√ßon.

@jrieken Avez-vous un groupe Slack ou ailleurs pour discuter de ce probl√®me¬†? Je peux aider :) J'ai pu extraire, d√©velopper et d√©boguer les modifications actuelles de la branche master. J'ai corrig√© les fichiers "ajout√©s" affich√©s en tant que "U" et j'ai m√™me ajout√© la prise en charge "mise en sc√®ne". Comme c'√©tait la premi√®re fois que je participais au projet, je le r√©initialise pour le ma√ģtriser et le recommence. J'ai fait un tas de changements, et je veux entrer comme un chirurgien et non comme une arme nucl√©aire.

Pourquoi y a-t-il des chèques sur raw.x + raw.y suivis de chèques sur raw.x puis raw.y ? Il semble qu'il corresponde à 2 statuts différents.

Pourquoi y a-t-il 2 constantes d'état pour ADDED / INDEX_ADDED , MODIFIED / INDEX_MODIFIED , et quelques autres ? Je comprends tous les différents statuts git, mais il serait logique de les gérer pour l'utilisateur final, pas pour nommer les statuts Git. ADDED doit être utilisé pour ce que vous avez maintenant en tant que UNTRACKED pour ensuite avoir un code de paramètres de git.color.added . Je pense que quelques-unes de ces constantes d'état sont dupliquées et devraient être simplifiées et nettoyées.

Un statut git de _M <-- underscore = space/nothing, correspondrait √† raw.y et vous l'avez comme INDEX_MODIFIED . Ceci est incorrect, le statut o√Ļ x = rien et y = M signifie staged .

Pour une raison quelconque, parfois au hasard, il semble ne pas refl√©ter les changements. De plus, il semble que les changements d'√©tat de git scannent de mani√®re r√©cursive de haut en bas. Si vous avez un gros projet, vous pouvez voir le statut ¬ę¬†ignor√©¬†¬Ľ s'√©couler dans vos dossiers/fichiers. Pour l'acc√©l√©rer, naviguer plus profond√©ment, semblait l'activer pour ce r√©pertoire et les griser. -- Ce processus ralentit-il beaucoup le syst√®me/VSCode ? Quelqu'un l'a-t-il compar√© ? Il n'est vraiment pas n√©cessaire de parcourir chaque fichier/dossier lorsque le parent est ignor√©. Les enfants devraient obtenir leurs statuts de leurs parents. -- Si vous avez 5 000 fichiers ignored mais tous dans 2 r√©pertoires (c'est-√†-dire : node_modules, vendor) alors nous ne devrions pas traiter 5 000 fichiers, juste 2 r√©pertoires qui contr√īlent l'apparence de leurs enfants.

Je vais refaire mes modifications plus tard dans la journée et publier un PR.

Merci encore pour votre travail. J'essaie juste de vous aider au lieu de vous harceler, car je peux le faire lol

@WadeShuler, je peux répondre à certaines de ces questions. Je suppose que vous recherchez dans Repository.updateModelState() dans repository.ts. Si vous notez les vérifications raw.x + raw.y, elles retournent toutes, vous ne pouvez donc pas faire les raw.x et raw.y. La raison pour laquelle raw.x et raw.y sont séparés, et la raison pour laquelle INDEX_* est que chaque INDEX_* est mis en scène, c'est juste ce qui est mis en scène qui change. Si vous remplacez INDEX par STAGE, je pense que cela a plus de sens, bien que la logique qu'ils utilisent soit techniquement correcte. Voir https://git-scm.com/docs/git-status , en particulier le tableau "XY Signification"
(EDIT : wow, le formatage était mauvais. Il suffit d'aller à l'original. C'est un tableau en rouge à peu près à mi-chemin.)
C'est clairement ce qu'ils utilisent pour tout ça.

Et je pense que vous vous trompez dans le cas _M, qui correspondrait √† MODIFIED, Index non modifi√© (c'est-√†-dire non mis en sc√®ne). √Ä moins bien s√Ľr que vous ne cherchiez un duplicata de ce code ailleurs.

@petkahl Merci, je connais le format court Git Status . Je l'ai utilisé il y a des semaines pour faire mon correctif de statut vsc git pour ajouter des statuts Git de base jusqu'à ce que cela soit résolu officiellement.

Il est possible (en quelque sorte) d'obtenir _M (trait de soulignement = espace). Je ne sais pas comment, pourquoi, quand .. J'ai eu cela plus t√īt dans la journ√©e (ainsi qu'il y a quelques semaines lorsque je travaillais sur mon Gist):

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

Maintenant, quelques heures plus tard, je le lance et j'obtiens "A". Je ne sais pas ce qui a changé depuis...

‚ěú  git-test git:(master) ‚úó git status -s --ignored         
A  added.php
A  test2.php
?? untracked.php
!! vendor/

Lorsque je faisais des recherches pour mon Gist, je pense avoir conclu qu'il était possible d'obtenir "A_" et "_M" pour la mise en scène. J'avais également trouvé un site qui avait détaillé le statut beaucoup plus clairement que la documentation git-status, je ne peux tout simplement pas le retrouver lol.


Vous pouvez √©galement obtenir ¬ę¬†AM¬†¬Ľ pour un fichier mis en sc√®ne et modifi√©. Cr√©ez un nouveau fichier vide, ajoutez-le (mettez-le en sc√®ne), modifiez le fichier et enregistrez, v√©rifiez l'√©tat¬†:

‚ěú  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/

Cela devrait-il donc avoir 2 badges, "[S][M]" ? Je préférerais savoir quels fichiers j'ai mis en scène. Il est utile lors de la cueillette des cerises. Il peut être utile de voir encore si vous avez modifié un fichier intermédiaire. Il devrait au moins avoir un badge mis en scène.

@WadeShuler Je peux toujours obtenir _M, en m'engageant et en modifiant. Ce qui signifie qu'il est inchangé (_=espace) dans l'index, mais modifié dans l'arbre de travail.
donc:
Créer un fichier : ??
git ajoute le fichier A_
git commit (pas dans status, mais l'équivalent de space space)
modifier le fichier : _M
git ajoute le fichier M_
modifiez-le à nouveau : MM

Je n'ai pas vraiment d'avis sur les badges quand il y en a deux. Je ne me connecte jamais sans regarder la fenêtre de statut, qui la décompose clairement, tout comme le fait le statut git ordinaire. Peut-être juste un paramètre qui vous permet de choisir celui qui a la priorité ? Je pouvais voir des arguments pour les deux. Ou deux badges, je suppose. En serait-il de même pour la coloration ?

J'ai ajouté le support Staged . Vous pouvez voir les changements ici : WadeShuler/ vscode:gitstatus-fix . J'ai également amélioré l'apparence de certains badges de l'onglet Statut de Git en les agrandissant un peu.

Pour une raison quelconque, il a supprimé l'assombrissement/l'ignorance du répertoire vendor , mais son contenu est toujours grisé et ignoré. Je ne comprends pas pourquoi ma simple modification a cessé de griser le répertoire vendor ? C'est le seul problème avec ce que je viens de faire, et pourquoi je n'ai pas encore émis de RP...

git-status-staged-updates

Si les couleurs/ic√īnes des fichiers mis en sc√®ne doivent √™tre incluses, cela devrait certainement √™tre facultatif. Personnellement, je pr√©f√©rerais ne pas voir la mise en sc√®ne dans ma liste comme une couleur diff√©rente de la couleur d'origine nouvelle/modifi√©e.

Une fois que vous commencez à inclure une mise en scène, cela peut vite devenir compliqué car il y a la possibilité d'inclure toutes les combinaisons et permutations de nouveau/nouvelle-étape/modifié/modifié-étape/modifié-étape-modifié/nouvelle-étape-modifié, etc. , ce qui conduira à une énorme matrice de couleurs et de confusion.

Je vote que nous ne compliquons pas trop les choses.

Je suis d'accord @dseipp. C'est la raison exacte pour laquelle je n'ai pas fusionné la prise en charge des fichiers mis en scène dans mon hack initial lorsque je l'ai fait, car je ne voyais aucune utilité à colorer les fichiers mis en scène.

Le but de la mise en √©vidence des couleurs est qu'il me permet de trouver des fichiers nouveaux/modifi√©s en un coup d'Ňďil dans l'explorateur de fichiers. Si je mets en sc√®ne certains fichiers, c'est g√©n√©ralement avant le commit ou si j'en ai fini avec eux, donc je n'ai aucune utilit√© pour qu'ils soient color√©s normalement.

Si nous ajoutons de la couleur pour chaque type de statut git possible, l'explorateur de fichiers commencera √† ressembler √† un arbre de No√ęl et il sera tr√®s d√©routant de voir ce qui se passe r√©ellement.

@jrieken Un autre rapport de bogue, arrive sur les tout derniers initiés :

  • Version VSCode¬†: Code¬†-¬†Initi√©s 1.18.0-initi√© (82dcf9835265cd0a45ec135587ae2a82673f1c8f, 2017-10-20T04:24:25.632Z)
  • Version du syst√®me d'exploitation¬†: Windows_NT x64 10.0.15063

Fondamentalement, VS Code "oublie" de temps en temps que certains fichiers sont modifiés et doivent être colorés en conséquence. Par exemple, j'ai 6 fichiers modifiés en ce moment. VS Code (correctement) affiche le numéro "6" sur le bouton git. Mais, dans l'arborescence des fichiers du projet, je ne vois qu'UN seul fichier en jaune, les cinq autres fichiers semblent ne pas avoir été modifiés. Chose intéressante, les 6 fichiers sont correctement colorés dans la section des éditeurs ouverts.

@dseipp Cela pourrait être facultatif. Cependant, vous ne verrez jamais la couleur "mise en scène" jusqu'à ce que vous mettiez en scène les fichiers... Elle n'est donc même pas vue 99% du temps et ne devrait vraiment déranger personne...

@ karabaja4 Je ne suis pas d'accord pour dire que cela n'a pas d'utilité. Vous avez fait remarquer que vous n'utilisez/remarquez/n'avez jamais besoin de coloration par étapes...

Le but de la mise en √©vidence des couleurs est qu'il me permet de trouver des fichiers nouveaux/modifi√©s en un coup d'Ňďil dans l'explorateur de fichiers. Si je mets en sc√®ne certains fichiers, c'est g√©n√©ralement avant le commit ou si j'en ai fini avec eux, donc je n'ai aucune utilit√© pour qu'ils soient color√©s normalement.

Donc même si cette fonctionnalité est ajoutée, cela ne devrait pas vous déranger...

Être capable de voir les fichiers mis en scène aide à choisir ce que vous êtes sur le point de commettre. Si nous avons 100 fichiers modifiés, nous devons les regrouper, nous pouvons parcourir l'arborescence des fichiers et voir facilement ce qui est mis en scène, et repérer ceux que nous avons manqués, pour nous assurer qu'ils sont dans le même commit.

Combien de fois avez-vous commis une poignée de fichiers, puis réalisé que vous en avez manqué un ? Vous avez alors 2 options, modifier votre dernier commit pour inclure les fichiers manqués, ou faire un nouveau commit. Lorsque vous travaillez avec des équipes, il est plus propre et moins déroutant de les avoir dans le même commit.

Au stade de la mise en scène, peu importe si le fichier a été ajouté, modifié ou autre chose.


Pour être honnête, la façon dont Visual Studio Code gère Git est chic et boguée. De grandes arborescences de fichiers, vous pouvez littéralement regarder la coloration couler à travers les fichiers/dossiers. Il laisse tomber la coloration au hasard...

Je pense que l'ensemble des besoins de support de Git a été réécrit à partir de zéro.

Je voudrais également exprimer mon soutien à la coloration des fichiers mis en scène (facultatif tant que je peux l'activer).

Voici mon flux de travail¬†: je commence √† travailler sur certaines fonctionnalit√©s/corrections de bugs, je passe √† l'√©tat ¬ę¬†OKish¬†¬Ľ, ce qui signifie que le code fonctionne plus ou moins mais n√©cessite quelques polissages/tweaks/nettoyage ou refactorisation. √Ä ce moment-l√†, je mets en sc√®ne mes changements. Effectuez ensuite le nettoyage et la refactorisation. Si la refactorisation √©choue ou devient trop compliqu√©e, je reviens simplement √† l'√©tat par √©tapes.

Avoir la possibilité de voir quels fichiers je suis en train de modifier est très bénéfique, et lorsque je mets en scène les modifications, je ne veux pas perdre toutes ces informations et accéder à l'arborescence sans couleurs.

@vvs Je suis d'accord pour que les fichiers mis en scène ne perdent pas leurs couleurs. Les couleurs doivent rester jusqu'à ce qu'elles soient engagées. Je préférerais simplement que la couleur mise en scène conserve les couleurs nouvelles/modifiées et que la ou les couleurs mises en scène supplémentaires restent facultatives.

Peut-être que Staged peut conserver les mêmes couleurs mais simplement ajouter une sorte de surbrillance ou de gras pour lui donner du contraste.

Il pourrait être utile de regarder l'art antérieur .. ne me souviens pas avoir vu un indicateur mis en scène, mais peut-être que les temps ont changé

Les ic√īnes dans l'explorateur de fichiers pour les fichiers modifi√©s/non mis en sc√®ne/... sont-elles vraiment n√©cessaires¬†? J'ai quelques probl√®mes d'attention, donc les couleurs et les ic√īnes me distraient tr√®s facilement. Ne pourrait-il pas √™tre facultatif et d√©sactiv√© par d√©faut¬†? Suis-je le seul √† √™tre distrait par eux ?

Du point de vue de l'exp√©rience utilisateur, parfois moins c'est plus, et beaucoup ne chercheront pas la possibilit√© de d√©sactiver ces choses et continueront √† souffrir ou m√™me √† changer d'√©diteur. Je pense que ce serait une bonne chose d'y r√©fl√©chir et de d√©cider si cela est vraiment n√©cessaire pour une meilleure UX (je suppose que c'est le but de ces ic√īnes.)

* Je n'ai pas eu le temps de lire tous les commentaires sur ce probl√®me, alors s'il vous pla√ģt dites-moi si ce que je demande quelque chose qui a d√©j√† √©t√© discut√© et je prendrai mon temps pour tout lire d√®s que possible pour √™tre en phase avec Ce qui fut dit. Merci.

Je pense que ce serait une bonne chose d'y r√©fl√©chir et de d√©cider si cela est vraiment n√©cessaire pour une meilleure UX (je suppose que c'est le but de ces ic√īnes.)

https://github.com/Microsoft/vscode/issues/178#issuecomment -336960308 est la raison pour laquelle nous avons des couleurs et des badges par défaut. Convenu que cela rend l'interface utilisateur un peu plus encombrée, ouverte aux suggestions accessibles/incluses mais aussi lisses et propres.

@jrieken Merci ! Pouvez-vous m'indiquer le commit qui a introduit les badges ? Je vais essayer de trouver quelque chose qui serait bénéfique pour les deux problèmes (avoir des difficultés à voir les couleurs ou ne pas savoir à quoi ça sert, et des problèmes de distraction).

vscode-git

@jrieken Prenons une page de Xcode et

Les badges sont utiles pour faire allusion aux débutants, mais cela devient encombrant une fois que les couleurs sont apprises.

Pour plus de remise √† v√©lo, je pr√©f√®re les badges color√©s en git.color.ignored (_left_ ci-dessus) car ils ont la m√™me importance visuelle. C'est-√†-dire, disparais-toi mais ne disparais pas au cas o√Ļ j'aurais besoin de toi.

Si nous impl√©mentons des badges subtils, les badges de la barre lat√©rale de contr√īle de code source doivent √™tre mis √† jour pour plus de coh√©rence.

Quelle que soit la direction prise par la discussion sur le badge, la conception du badge pourrait-elle au moins être cohérente avec celles de la barre latérale Git ? Il semble un peu décousu d'avoir un design pour la barre latérale Explorer et un autre pour la barre latérale Git.

J'aime la suggestion d'une

Si nous impl√©mentons des badges subtils, les badges de la barre lat√©rale de contr√īle de code source doivent √™tre mis √† jour pour plus de coh√©rence.

Cela arrivera, c'est dans mon plan pour octobre.

J'ai mis à jour https://github.com/Microsoft/vscode/issues/178#issuecomment -335511695 avec les dernières captures d'écran et noms de couleurs. De plus, avec l'initié de demain, nous afficherons les mêmes badges dans la vue SCM, mais pas d'étiquettes colorées. Ainsi

oct-24-2017 19-55-03

C'est plus beau @jrieken - Merci pour vos efforts continus. Je pense que les badges ont l'air beaucoup mieux !

Le badge devrait-il être U ? Je pense que la communauté devrait peser. Le U me fait d'abord penser à updated . Je sais que c'est untracked dans la terminologie Git, mais je pense que A est plus approprié, surtout pour ceux qui ne connaissent pas les termes sous-jacents, que U n'est pas suivi. - Personnellement, je vote pour A pour ajouté. Comme dans, il a été ajouté à votre référentiel.

Puis support pour staged (optionnel via les param√®tres) et c'est assez proche ūüĎć

@WadeShuler , que diriez-vous d'un point d'interrogation (?) pour non suivi ? Je n'aime pas A car il a une connotation différente pour git que celle que l'on entend ici, du moins dans mon esprit.

Edit : Mais je suis d'accord que U pourrait être déroutant.

Je pense que je serais bien avec un point d'interrogation. Cependant, je ne pense pas que Code
ne prend en charge que Git, n'est-ce pas ? Je ne pense pas que nous devrions le regarder visuellement dans
l'√©diteur comme "Git", mais plus de contr√īle de version en g√©n√©ral.

Quoi qu'il en soit, j'aime vraiment pas "U" lol

Le mardi 24 octobre 2017 √† 14h20 Peter Kahle [email protected]
a écrit:

@WadeShuler https://github.com/wadeshuler , que diriez-vous d'un point d'interrogation
(?) pour non suivi ? Je n'aime pas A car il a une connotation différente pour
git que ce que l'on entend ici, du moins dans mon esprit.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/Microsoft/vscode/issues/178#issuecomment-339084261 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AJHVkJJNzw89umFiPB0BmgQAZYJNXTHzks5svip7gaJpZM4GlYyH
.

Assez juste, il devrait √™tre agnostique. Mais "Inconnu du syst√®me de contr√īle de version" en tant que ? a du sens pour moi. Mais N (pour New) pourrait √©galement fonctionner, et je ne peux penser √† aucune surcharge pour celui-ci, m√™me si je suis s√Ľr que quelqu'un d'autre le fera.

Oui, @jrieken , vos efforts sont grandement appréciés ! Vous avez l'air vraiment bien ! Les badges subtils sont un plus.

Je suis avec @WadeShuler et @petkahl pour vouloir changer le U en autre chose. Le 'N' ou '?' travail. Cependant, je penche vers le N car alors ce serait 'Nouveau et 'Modifié.

H√Ęte de voir cela se r√©unir¬†!

Est-ce que workbench.colorCustomizations.git.color.ignored fonctionne pour tout le monde ?
Je suis sur la dernière mise à jour de 1.18.0-insider aujourd'hui et la couleur ignorée n'est toujours pas prise en compte. De plus, il semble que "_deleted_" et "_conflict_" ne fonctionnent pas encore... peut-être avec la mise à jour de demain,
Mais ce qui me dérange, c'est la couleur ignorée. Le nom du fichier ressemble à un fichier versionné - non modifié, ce qui signifie qu'aucune couleur spéciale ne lui est appliquée.
Remarque : le d√©p√īt dans la capture d'√©cran n'a aucun fichier suivi. Tous les fichiers ne sont pas suivis. Une fois que j'ai supprim√© "_shared.module.ts_" de .gitignore , il appara√ģt en marron (mon param√®tre de couleur non suivi).

image

Le badge devrait-il être U? Je pense que la communauté devrait peser. Le U me fait d'abord penser à jour. Je sais qu'il n'est pas suivi dans la terminologie Git

Nous avons d√©j√† utilis√© "U", ce n'est pas la bonne question pour discuter de ce qui est mieux, mais je pense que les utilisateurs de git connaissent la terminologie et pour les autres fournisseurs de SCM, d'autres lettres/ic√īnes peuvent/devraient √™tre utilis√©es (et c'est le cas aujourd'hui).

Cette fonctionnalité n'a pas été ajoutée, et je suis actif dans ce fil depuis
ça a commencé à avancer. J'ai mentionné le badge "U" depuis le début.

Ce fil concerne le développement et l'aplanissement de l'ensemble de la fonctionnalité, car
c'est nouveau. Si la couleur de la police, le style du badge et les couleurs du badge sont tous acceptables
à discuter dans ce fil, alors les lettres le sont aussi.

Alors, o√Ļ d'autre, en dehors de ce fil, avons-nous utilis√© ¬ę¬†U¬†¬Ľ¬†?

Alors, o√Ļ d'autre, en dehors de ce fil, avons-nous utilis√© ¬ę¬†U¬†¬Ľ¬†?

Vérifiez stable, pas les initiés, et la vue SCM avec git. Il utilise un U pour u ntracked fichiers.

@WadeShuler @jrieken La U gris et un _fichier ajouté_ avec un A vert . git status affiche les _fichiers ajoutés (mis en scène)_ en vert ANSI .

Je comprends donc la confusion avec un U vert pour un _fichier non suivi_. Je prévois aussi que mes yeux me font mal à cause des U verts se mélangeant aux A verts .

Atom colore les nouveaux fichiers non suivis et mis en scène en vert , et Xcode marque les fichiers ajoutés comme A tant qu'il s'agit d'un nouveau fichier. Les deux ne m'ont jamais dérangé le moins du monde (mais un U vert le fait).

Je suis donc tout à fait d'accord pour utiliser les A verts pour les nouveaux fichiers _et_ mis en scène non suivis.

Continuons le 'U' vs 'A' vs '?' discussion sur https://github.com/Microsoft/vscode/issues/36912. Merci.

Je suis d'accord. Je pense qu'il vaut mieux continuer avec les lettres utilisées dans l'interface aujourd'hui. Je n'aime pas non plus le "U", mais je pense que cela sort un peu du cadre de cette demande de fonctionnalité. Si cela change, cela devrait changer dans tout le programme.

OK, c'est un fil énorme et je n'ai que le temps de le lire, donc je vais juste dire ici : j'espère qu'il y a un paramètre pour le désactiver. Je préfère tous les noms de fichiers de la même couleur et quand j'ai besoin de voir leur statut, je tape git status . :-)

Ce produit est-il abandonné ? Semble être.

Actuellement, list.activeSelectionForeground semble avoir la priorité sur le style d'état git, donc les couleurs d'état git ne peuvent pas être vues dans le fichier sélectionné. Je trouve cette information utile d'avoir, même sur le fichier actuellement sélectionné. Y a-t-il une chance que le style du statut git soit prioritaire lorsque explorer.decorations.colors est vrai ?
Ce comportement a été observé sur les initiés 1.18 8dfa696.

Actuellement, list.activeSelectionForeground semble avoir la priorité sur le style d'état git, donc les couleurs d'état git ne peuvent pas être vues dans le fichier sélectionné.

En effet, idem ici sur les tout derniers initiés (juste mis à jour). Lorsque je clique sur le nom du fichier dans l'arborescence du projet, la couleur de l'entrée du fichier est modifiée (par exemple, de jaune/modifié à neutre). Je pense aussi que c'est un comportement assez déroutant. La couleur du fichier ne doit pas changer lorsque l'utilisateur clique sur le fichier.

Btw, le même problème avec la liste des fichiers ouverts, lorsque vous cliquez sur le fichier là-bas, la couleur d'état git est remplacée par la couleur de sélection neutre.

Btw, le même problème avec la liste des fichiers ouverts, lorsque vous cliquez sur le fichier là-bas, la couleur d'état git est remplacée par la couleur de sélection neutre.

Eh bien, cela a été fait exprès car la couleur de sélection de premier plan entre souvent en conflit avec les couleurs de décoration. Ajouter plus de couleurs, comme git.untrackedSelectedForeground et git.untrackedFocusedForeground ne nous a pas semblé très attrayant. Par conséquent, nous laissons la couleur de sélection l'emporter lorsqu'un élément est sélectionné et a le focus.

Atom ne semble pas avoir de problème avec ça...

atom-selected-color

Il n'y a pas besoin de nouveaux paramètres... Les thèmes seront mis à jour pour s'adapter si la couleur d'arrière-plan de l'élément sélectionné interfère. Ceux qui ne le font pas, la communauté décidera de ne pas utiliser ces thèmes.

Je n'ai pas vérifié, mais j'espère que les "badges" (c'est-à-dire: U, M) ne sont pas toujours des fichiers svg. Ils devraient juste être du texte brut qui peut être stylisé/coloré.

Honn√™tement, VSCode aurait d√Ľ simplement utiliser des feuilles de style pour ces choses au lieu de param√®tres de configuration maladroits. Cela a compliqu√© un processus assez simple.

@WadeShuler Il y a une sélection et une mise au point et parce que je vois un curseur d'éditeur dans votre capture d'écran, je pense que votre élément est uniquement sélectionné, pas mis au point. En fait, je ne vois pas de différence dans Atom entre sélectionné et focalisé. C'est comme ça dans VS Code

sélectionné mais pas focalisé

screen shot 2017-11-01 at 16 16 35

sélectionné et concentré
screen shot 2017-11-01 at 16 16 47

@jrieken J'ai vérifié deux fois, et dans mon Atom, sélectionné vs focalisé produit le même résultat. Il ne perd jamais la couleur de police yellow dans la fenêtre de gauche de l'explorateur de fichiers. Dans votre 2ème capture d'écran, la couleur red est perdue à partir de test.foo , ce qui est le problème.

J'ai essayé les thèmes Atom sombre et clair par défaut, ainsi qu'environ 3 autres thèmes. Ma valeur par défaut (comme vous le voyez dans mon SS) est Seti (à la fois l'interface utilisateur et le thème). Je ne parviens pas à faire en sorte qu'Atom supprime la couleur yellow de l'explorateur de fichiers, quoi que je fasse. Atome version 1.21.2.

Choisi
selected

Sélectionné & Concentré
selected-focused

Prêt à l'emploi, VS Code doit conserver la couleur d'état git quels que soient les états sélectionnés ou ciblés.

Si votre problème concerne les thèmes, ce n'est pas votre problème. C'est la responsabilité des développeurs de thèmes de mettre à jour et de s'adapter.


Remarque : je n'ai pas consulté les derniers initiés ni consulté le code, mais les fichiers git ignored doivent utiliser opacity pas une couleur de police, donc c'est toujours x plus sombre que les fichiers normaux, quelle que soit leur couleur.

@WadeShuler merci pour vos commentaires sur la façon dont les gestionnaires de thèmes doivent gérer leurs affaires ! Comment l'équipe VSCode ose-t-elle fournir une API pour les aider à le faire ? Ces développeurs paresseux !

@fernandofleury Personne n'a parlé de ne pas fournir aux gestionnaires de thèmes une API pour le gérer. Mon message n'a rien dit de tel. Donc, votre commentaire sarcastique est tout simplement invalide et injustifié.

@jrieken a dit :

Eh bien, cela a été fait exprès car la couleur de sélection de premier plan entre souvent en conflit avec les couleurs de décoration.

J'ai dit:

Si votre problème concerne les thèmes, ce n'est pas votre problème. C'est la responsabilité des développeurs de thèmes de mettre à jour et de s'adapter.

Le problème serait un conflit entre la couleur de premier plan (en fait, c'est une couleur d'arrière-plan) de l'élément de l'arborescence du fichier/dossier (normal, sélectionné, ciblé) et les choix de couleur de police pour les différents statuts git.

Cela _serait_ la responsabilité des développeurs de thèmes. Ils doivent choisir à la fois les couleurs de premier plan des éléments de l'arborescence et les couleurs de police pour les différents statuts git afin qu'ils n'entrent pas en conflit.

Par exemple : un développeur de thème a ThemeX et sa couleur de police pour les éléments de l'arborescence des fichiers de l'explorateur est yellow . Eh bien, sa couleur de police par défaut entrerait en conflit avec la couleur de statut par défaut de yellow git. Vous ne seriez plus en mesure de savoir quels fichiers sont modifiés. Ce serait donc la responsabilité des développeurs de thèmes ! -- Il en va de même pour la couleur d'arrière-plan des éléments sélectionnés/sélectionnés dans l'arborescence des fichiers de l'explorateur par rapport aux couleurs de police des statuts git.

Est-ce reporté maintenant ?

@IljaDaderko Je ne pense pas, car cela appara√ģt dans la prochaine note de version v1.18 de la prochaine version stable. La question pourrait √™tre plus, est-ce que cela sera ferm√© ou y a-t-il encore plus de travail √† faire ?

@IljaDaderko VSCode v1.18 est déjà sorti et il inclut les changements discutés ici.

Les couleurs de fichier ignorées sont-elles censées faire partie de la mise à jour v1.18 ? Les documents disent que gitDecoration.ignoredResourceForeground peut être utilisé pour colorer les fichiers ignorés, mais jusqu'à présent, je n'ai pas pu voir que cela affecte quoi que ce soit. La coloration modifiée/non tracée fonctionne cependant très bien. C'est sur stable 1.18.0, Windows.

Idem ici (à propos de la couleur ignorée). Cela n'a pas fonctionné pour moi non plus, depuis que toute cette implémentation de Git a commencé. Utilisation d'initiés.
Tout ce que fait gitDecoration.ignoredResourceForeground est d'ignorer les fichiers ignorés de la coloration :)

Cela fonctionne pour moi et cela a l'air SPECTACULAIRE.

Enfin c'est ici

@arxpoetica Voici ce que j'obtiens :
image

Comment ça peut marcher pour certains et pas pour d'autres, je ne comprends pas. C'est juste ce paramètre gitDecoration.ignoredResourceForeground
Suis-je le seul pour qui ça ne marche pas ? Vraiment personne d'autre ? :) Oh, et @Shurelia
Quelqu'un d'autre (nous, utilisateurs) a-t-il réellement testé la définition de la couleur ignorée avant de dire que cela fonctionne ?

Système d'exploitation : Windows 10 PRO (1709)
VSCode¬†: 1.19.0-insider (juste mis √† jour plus t√īt)
Idem sur mon ordinateur portable de travail et mon ordinateur de bureau à domicile.

Est-ce dans Insiders ? Comment puis-je l'utiliser?

Félicitations, tout le monde !

@nkkollaw Dans les deux initiés et stables (1.18)

@MrCroft Veuillez discuter des problèmes de git-ignore ici : https://github.com/Microsoft/vscode/issues/37857

Comme nous avons intégré cette fonctionnalité dans notre dernière version stable, il est temps de fermer et de verrouiller ce problème. Veuillez créer de nouveaux problèmes pour les discussions sur les sujets et les rapports de bogues. Les problèmes autour de cette zone sont marqués avec le file-decorations -label.

Tout le monde, merci pour les commentaires formidables et continus qui ont fait de cette fonctionnalité ce qu'elle est !

Pour résumer et répéter mon commentaire précédent .

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

Un certain nombre de choses

  • Par d√©faut, il y a une combinaison de couleur et de bagde.

    • activer/d√©sactiver les ic√īnes avec¬†: "explorer.decorations.badges": true|false

    • activer/d√©sactiver les couleurs avec "explorer.decorations.colors": true|false

  • Les couleurs s'affichent dans l'arborescence des fichiers, dans la section des √©diteurs ouverts et dans la vue SCM
  • Il y a trois couleurs pour commencer. Vous pouvez les personnaliser dans le param√®tre workbench.colorCustomizations . Les couleurs sont gitDecoration.modifiedResourceForeground ,
    gitDecoration.deletedResourceForeground ,
    gitDecoration.untrackedResourceForeground ,
    gitDecoration.ignoredResourceForeground , et
    gitDecoration.conflictingResourceForeground
Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

chrisdias picture chrisdias  ¬∑  3Commentaires

shanalikhan picture shanalikhan  ¬∑  3Commentaires

v-pavanp picture v-pavanp  ¬∑  3Commentaires

omidgolparvar picture omidgolparvar  ¬∑  3Commentaires

mrkiley picture mrkiley  ¬∑  3Commentaires