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