• 1

Seria legal se isso fosse exposto como uma extensão de alguma forma. Eu me preocupo que, em alguns casos, a árvore possa estar um pouco poluída de cor e parecer uma árvore de Natal. Ou se não, pelo menos tem a opção de ligá-lo e desligá-lo.

Sim eu concordo. Eu criei um problema separado para ter isso exposto na API de extensão (consulte # 1394).

+1

Adoraria isso também. A guia Git é muito útil, mas isso é para outro propósito - ter cores como no Atom seria muito complementar para ver rapidamente o que mudou e onde (com a cor propagando-se automaticamente até o diretório superior). Esse é provavelmente o recurso que mais sinto falta do Atom.

Normalmente, você não tem 10s ou 100s de arquivos modificados não confirmados, então é improvável que se pareça com uma árvore de Natal :)

Portanto, parece que o PR para isso foi fechado. @bpasero @joaomoreno - alguma atualização sobre o status deste trabalho?

Verifique https://github.com/Microsoft/vscode/pull/8462

Sem atualizações ...

Muito obrigado pelo seu interesse neste assunto! Atualmente, está atribuído ao backlog. Todos os meses, selecionamos itens do backlog para planejar a iteração atual. Consulte https://github.com/Microsoft/vscode/wiki/Issue-Tracking#planning para obter mais informações.

Como somos uma pequena equipe de desenvolvedores, há apenas algumas solicitações de recursos e problemas com os quais podemos trabalhar em um marco. No entanto, sempre recebemos solicitações de pull e ficamos felizes em aceitá-las se atenderem aos nossos padrões de qualidade.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Pare de escrever +1 . Envia e-mails para todos os envolvidos. Use as reações do emoji no primeiro comentário.

+1

Olá, você tem alguma notícia sobre esta solicitação de recurso? Comecei a usar o vscode hoje e já estou amando mas sinto muita falta das cores que indicam as mudanças
Parabéns pelo seu trabalho

+1

Ao implementar isso, por favor, considere 206

Eu adicionei algumas capturas de tela para ajudar:

Atom default:

VSCode padrão:

+1

+1

Isso seria muito útil.

já existe a capacidade de modificar a maneira como os arquivos e ícones são listados na árvore de arquivos.
Esta extensão faz isso
https://github.com/robertohuertasm/vscode-icons.

Não altera os nomes dos arquivos, no entanto

+1

+1

existe alguma mudança? Este recurso me impede de sair do Atom. :(

Acabei de me mudar do Atom porque o desempenho parece muito melhor no VSC. No entanto, esse é um recurso de luxo do qual sinto falta no VSC.

+1

Acho que seria bom ter isso como uma configuração embutida (por exemplo, git.colorExplorer ) em vez de uma extensão.

@arkon existe alguma extensão desse tipo? Não consegui encontrar nenhum.

Provavelmente, o explorador de arquivos não tem uma API para modificá-lo de acordo
para fazer alterações. Uma extensão seria bom para mim.

Na sexta-feira, 3 de fevereiro de 2017, 07:52 Rahul [email protected] escreveu:

@arkon https://github.com/arkon existe alguma extensão desse tipo? Não pude
encontre algum.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/178#issuecomment-277177373 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AEQJ1eoLm7Sp59a2hE0tIFQnb0Q5cJnSks5rYs6tgaJpZM4GlYyH
.

@ rahulnever2far Não, foi apenas uma sugestão, já que foi sugerido anteriormente que ela poderia ser exposta como uma API de extensão (o que também está bom, suponho).

Decidi recentemente mudar para o VSCode e sinto muita falta desse recurso

Por favor adicione. Adiciona atrito à produtividade ao tentar pular do Atom.

@KozhokarAlex @bhudgens e outros: clique no ícone de polegar para cima na primeira postagem para mostrar aos desenvolvedores que você está solicitando esse recurso. Eles classificam os problemas com polegares para

Como você pode ver neste tipo de classificação de problemas, este é o terceiro recurso mais solicitado no momento.

Afirmativo. Vim recentemente do Atom ... espero vê-lo em VSCode em breve!

Ah obrigado @joaomoreno!

Adicione também o mesmo status de coloração / qit ao QuickOpen, não apenas ao FileExplorer.
Desta forma, os arquivos de abertura podem ser filtrados visualmente com base em arquivos já alterados.

O que está acontecendo com isso? por que os mantenedores não mesclam o @joaomoreno PR? existe um plugin que podemos usar agora? isso é apenas um plano bobo

@SOSANA Não tenho certeza do que você quer dizer com RP, a qual RP você está se referindo?

2824 abre a porta para consertar este, então seja um pouco mais paciente.

@SOSANA isso é um problema, não um PR 🤣

+1 este recurso seria incrível para a produtividade

+1

@ publiclass1 @ hevans90 , ... (insira todas as outras pessoas que comentaram com +1) ..., POR FAVOR , não poste comentários sobre o quanto você deseja este recurso. É para isso que o GitHub adicionou as reações de emoji. Apenas goste do comentário original. Assim posso voltar a usar as notificações por e-mail para o que se destinavam (mantenha-se atualizado sobre o andamento desse assunto, e não quem quer que seja no mundo também quer isso). Desculpe a todos por também enviar spam para vocês. Sinceramente, espero que mais pessoas aprendam a impedir +1 -ing problemas.

+1

Eu uso o PhpStorm, mas prefiro usar o VS Code para tudo. Atualmente, uso o máximo de janelas do VS Code que posso. Você pode eventualmente ter este sistema de coloração como uma opção já que eu prefiro / conheço as cores do PhpStorm. Para referência:

Preto - Atualizado - Arquivo inalterado.
Cinza - Excluído - O arquivo está agendado para exclusão do repositório.
Azul - Modificado - O arquivo foi alterado desde a última sincronização.
Verde - Adicionado - O arquivo está agendado para adição ao repositório.
Marrom - Desconhecido - O arquivo existe localmente, mas não está no repositório e não está programado para adição.

etc via https://www.jetbrains.com/help/phpstorm/2016.3/file-status-highlights.html . Vocês são demais, obrigado.

e

• arquivos que foram mesclados com conflitos são exibidos em vermelho,

é muito conveniente distinguir em conflito de outros

+1 Ter que alternar para frente e para trás entre as visualizações do Git <> Explorer é super improdutivo.

Idealmente, seria possível ver também o conjunto de alterações como um grupo no topo onde temos arquivos abertos, bem como uma árvore aninhada de alterações visualizadas por cor (como mostrado por @abdonrd acima).

Vamos rapazes, pare com o +1.

Coloque um polegar para cima na primeira postagem.

Eu tenho um caso de uso interessante e argumento para fazer uma API genérica que permitiria ao plug-in colorir arquivos e pastas individuais:

Envelhecimento de arquivo / pasta semelhante ao poder de envelhecimento do Trello - gostaria que os arquivos e pastas que não foram tocados por um longo tempo (a julgar pelo histórico do git) esmaecessem, para que o 'conjunto de trabalho' fosse mais distinto e mais fácil de encontrar.

Por que: eu tenho um grande repositório de projetos minúsculos (pense em um monte de scripts para relatório analítico) em que mais de 90% do trabalho não será tocado novamente (mas não posso mover o material antigo para a subpasta porque quebraria muitos links apontando para repo).

Se houvesse um endpoint de API para colorir itens de árvore, eu poderia escrever um plugin que lê o git log e colore cada arquivo / pasta de acordo com algum conjunto de regras.

E aí, ainda não existe uma API que permita criar uma extensão para isso, ou será implementada como um recurso integrado?

alguma atualização disso?

+1

+1

+1

Vocês podem parar de marcar com +1 e enviar spam para nossas caixas de entrada de e-mail ???

Não serve a nenhum propósito.

+1 para nenhum spamming xD

protip: filtrar mensagens do github em que o corpo é igual a / corresponde a / lolwuts "+1"

você não pode parar essas pessoas.

@jmbelloteau como @fredrikaverpil disse anteriormente nos comentários, os problemas do VSCode são classificados pelo número de polegares para cima do comentário original. Portanto, comentar "+1" em vez de adicionar uma reação ao primeiro comentário é realmente spam, pois não é a maneira correta de fornecer feedback e enviar apenas e-mails inúteis para todos. E ao contrário de adicionar uma reação, ela nem será levada em consideração.

+1

Estou tão acostumado com isso no Webstorm também: D. Mas, como posso ver, isso provavelmente será desenvolvido mais cedo ou mais tarde. Aqui está uma captura de tela do Webstorm para inspiração (seguindo @abdonrd):

Ah, também os arquivos não rastreados são mostrados em vermelho!

+1

Acabei de experimentar o código do VS pela primeira vez hoje (vindo do Atom) e uma das primeiras extensões que procurei foi "git status" destacando-se na visualização do explorer. A guia "controle de origem" por si só é muito boa, mas ter pastas / arquivos destacados me permite navegar rapidamente para o componente que estou trabalhando sem ter que sempre deixar minha árvore de diretórios expandida (muito útil para bases de código FE que tendem a têm estruturas aninhadas mais profundamente).

idealmente, seria ótimo se as cores pudessem ser modificadas individualmente.

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

+1

Faz um tempo que procuro um bom aplicativo para me lembrar de beber água.
Então, percebi que estou inscrito neste tópico.
Continue com o +1, pessoal, eles não são mais inúteis 🚰

@mmazzarolo
Por que você precisa de lembrete para beber água? Não é suficiente beber quando você está com sede?

De qualquer forma, pare de marcar com +1. Tenho certeza que os desenvolvedores já estão cientes disso e postarão atualizações assim que surgirem.

@pohmelie essa é uma alternativa válida, obrigado!

+1

O que há de errado com essas pessoas +1?

Ótima ideia, @ davidhu2000! Seria bom oferecer suporte a cores hexadecimais como git.ignoredFileColor: '#333333' também.

Há uma boa lista dos tipos e cores que o JetBrains usa aqui: https://www.jetbrains.com/help/idea/2017.1/file-status-highlights.html (você pode inspecionar o nome da cor para obter o hex).

+1 aumentando a conscientização sobre o quanto esse recurso é desejado

A única razão pela qual não estou usando o VS Code. Muito ruim :(

Alguém sabe onde na base de código se pode começar a implementar isso? Eu quero tentar.

@admosity Alguém já enviou uma solicitação de pull no ano passado que foi rejeitada: https://github.com/Microsoft/vscode/pull/8462 .

2824 foi mencionado como um bloqueador em algum lugar acima, que foi mesclado há algum tempo. Eu verificaria as mudanças lá para ter certeza de que foi implementado como a equipe VS deseja.

@AndreasGassmann incrível! Vou dar uma olhada.

O último recurso fundamental me impede de mudar para o código vs

Quando esse recurso for incorporado, vou mudar para vscode

Estou inscrito neste problema porque gostaria de saber quando algum progresso estiver feito.
Todos estão cientes de como esse recurso é desejado e agora é a segunda questão mais votada :).

Se você realmente deseja esse recurso, vote positivamente no primeiro comentário e evite adicionar comentários repetidos .

Para as pessoas que acham que esse recurso é necessário, mudar para o VS Code. Posso dizer que foi o primeiro recurso que perdi ao trocar do Atom, mas, IMO, esse é um pequeno preço a pagar por esse IDE incrível.
Além do mais, na semana passada eu tive que trabalhar no Atom e realmente senti falta do git view do VS Code.

@waderyan Este é um dealbreaker saindo do átomo.

Sim por favor!

+1

+1

+1

Fiz um hack muito feio que implementa esse recurso modificando workbench.main.js e injetando o CSS com base na saída de git status . Se você não se importa de vasculhar os arquivos internos do VS Code e fazer com que seu VS Code execute git status cada 5 segundos, dê uma olhada.

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

Atualização de 28.6.2017: Corrigido um bug em que o plugin não carregava ao reabrir o projeto.
Atualização 30.6.2017: Adicionado destaque de diretórios pai de arquivos modificados (como o Atom faz).
Atualização 1.7.2017: A correspondência de arquivos agora é feita usando o arquivo completo ou o caminho do diretório. Antes dessa mudança, o diretório era destacado se tivesse o mesmo nome de outro diretório alterado.

Olá,
Não consigo descobrir se esse recurso foi implementado ou ainda não?
Não encontrei nenhuma configuração ou extensão e, como foi aberto há quase dois anos, estou confuso.

@sanjibukai O problema ainda está aberto, então ainda não foi implementado. Você pode usar o hack que @ karabaja4 criou no comentário acima do seu.

Sou novo aqui, mas realmente preciso de quase dois anos para adicionar esse recurso óbvio?
Surpreendentemente, nunca ouvi falar sobre vscode até recentemente, mas quando ouvi sobre ele, o principal recurso que foi defendido é precisamente como o vscode é uma boa integração do git. E de fato é bom.
É uma pena que esse recurso ainda não tenha ..
No entanto, mantenha o bom trabalho da equipe vscode 👍

Não é possível manter o foco sem esse recurso. Sempre que preciso lembrar qual arquivo edito.

+1

@ karabaja4 por que você não faz um PR com seu hack e recebe feedback sobre como implementá-lo corretamente?

@saada Eu faria isso se achasse que algum desses códigos poderia ser integrado ao VS Code. Executar um processo git status certamente não é uma maneira sensata de implementar esse recurso. Qualquer código adequado que implemente isso deve ser escrito do zero e implementado corretamente dentro da estrutura de origem do VS Code. É muito trabalho e, infelizmente, de momento não tenho tempo disponível. Desculpa :(

Empilhar não vai ajudar em nada quando sua métrica declarada já é considerada o número de + 1s que o post original obtém, não nas respostas. Além disso, considerando que esta é uma ferramenta para desenvolvedores, estou meio surpreso com a quantidade de direitos e não entendendo o processo de código aberto que está acontecendo aqui. A solicitação de recurso está aqui como um problema em aberto. Você pode marcar com +1 na postagem e fazer você mesmo (provavelmente trabalhando com os mantenedores para ter certeza de que não será em vão) e solicitar uma fusão ou simplesmente deixar por isso mesmo. Se for um recurso vital para você, use o Atom. Enquanto escrevo isso, há mais de 4.000 questões em aberto. Você terá que exercitar a paciência.

(ou use @ karabaja4 hack entretanto - obrigado pelo seu trabalho!)

+1
Fazendo isso porque basta ouvir falar devchat e problemas com mais comentários receberão mais atenção

@ karabaja4 ótimo trabalho. Outra abordagem: que tal executar git status no init e atualizar sempre que o evento onFileSave for disparado? isso seria mais eficiente?

talvez pudéssemos configurar a maneira como atualizamos o status do git.

+1 isso seria muito útil se adicionado

@Kaijun Não tenho certeza de como implementaria isso. De onde viria o evento onFileSave ?

Se vier de Code no documento salvo (presumindo que eu saiba como anexar a ele), os arquivos modificados fora do Code serão ignorados, assim como alterações como mover e copiar arquivos.

Se vier de uma lógica de monitoração de pasta implementada na árvore da solução, isso deverá ser feito recursivamente para toda a árvore. Não tenho certeza se vale a pena em termos de desempenho.

@ karabaja4 Acho que o Code detecta mudanças externas também. Portanto, conectar-se a tal "evento" com talvez um sistema de debounce de modo que várias alterações de arquivo no mesmo intervalo não acionem muitas verificações de status git. Isso pode funcionar !. Talvez alguém familiarizado com a peça fs possa intervir?

Isso realmente não deveria estar no backlog. Há um valor muito real em adicionar esse recurso aparentemente pequeno. A felicidade do desenvolvedor vai ao longo do caminho. É desanimador ver que esse problema tem milhares de + 1s e é desconsiderado desde 2015.

@kamok é verdade! Embora o Atom seja lento, eu tinha outra opção ... Voltei ao WebStorm, que está invicto na forma como se integra ao Git além de outros recursos para os quais você tem que instalar extensões no vscode, e ainda consegue ser tão rápido e parece um editor leve em vez de um IDE, em termos de velocidade. Este recurso sozinho (status do Git no explorador de arquivos) ainda não seria suficiente para manter os usuários do vscode. Isso seria apenas uma gota no balde. É o recurso que menos sinto falta, vindo do WebStorm.
Eu sugiro que a equipe vscode dê uma olhada em como o pessoal da JetBrains está fazendo isso.
Sinto muito, mas eu tentei ... Eu tenho lutado com vscode por meses agora, esperei atualização após atualização, mas eu ainda me encontrava constantemente fechando o vscode e reabrindo o projeto no WebStorm para: Status do Git no explorer árvore, Stashes, visualização de pasta / árvore para mudanças locais, comparação de ramos, clique com o botão direito> comparar com a área de transferência ... E estes estão apenas no topo da minha cabeça. A integração do Vscode com o Git ainda tem um caminho muuuuito longo a percorrer se eles realmente quiserem ajudar os desenvolvedores.

_Enviado do meu Samsung SM-G950F usando FastHub _

@MrCroft , sugiro que você entre em contato com a equipe diretamente se estiver tão preocupado com a metodologia de trabalho deles, caso contrário, marque o problema com +1 com um polegar para cima e troque de editor se isso o incomodar tanto.

@cucumbur eu já fiz (troquei de vscode). Só estou declarando minha tristeza, porque realmente gostei de como era o vscode. Eu adoraria que ele tivesse uma boa integração com o Git para que eu pudesse continuar usando-o. Tenho certeza de que muitas pessoas sentem o mesmo.
Eu ainda vou ficar de olho nisso. Talvez, quem sabe, em um "futuro não muito distante" isso fosse feito ... Além do vscode, eu sou um grande fã da Microsoft ... Software e hardware, eles constroem coisas de altíssima qualidade 9 em 10 vezes . Só espero que o vscode se torne um dos 9.

_Enviado do meu Samsung SM-G950F usando FastHub _

@kamok Cada novo problema vai para o backlog e permanece lá até que seja resolvido. Não acho que esse recurso seja desconsiderado. apenas requer mais mudanças do que você imagina. Pelo que eu sei, eles querem que isso seja parte da API de extensões e, atualmente, a árvore de arquivos carece de muitos recursos para fazer isso acontecer.

Se você classificar os problemas com o polegar para cima, verá que este é o segundo mais popular, o primeiro está sendo trabalhado e quase pronto. Tenho certeza de que começarão a trabalhar nisso assim que o outro for concluído.

Uma atualização ocasional neste tópico seria ótimo.

Comutado do atom, mas em um projeto grande, sem os arquivos atualizados realçados, é difícil trabalhar com ele.
Alternando de volta para Atom até que este recurso esteja disponível

Talvez valha a pena mencionar que uma solução alternativa / provisória que funcionaria para mim ... é ter a estrutura em árvore duplicada na visualização "Editores Abertos". Normalmente, a visualização mostra arquivos "atualizados", mas é apenas um despejo de nomes de arquivos, muito mais difíceis de trabalhar, ao contrário de se estivesse claro onde esses arquivos são encontrados no projeto.

Alguma atualização sobre isso?

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

Sou masoquista - meu próprio comentário.

Eu continuo tentando o VSCode, mas como esse recurso está faltando, ele me impede de alternar. Não percebi o quanto confio neste recurso no Atom até tentar mudar.

Apenas esperando que isso mude para o código VS do atom, espero que seja implementado em breve.

+1

dois anos se passaram 。。。

e, surpreendentemente, seu comentário não acabou mudando isso. Aqueles de nós que se preocupam com o desenvolvimento e potenciais contribuições se inscrevem nos tópicos de assunto, seu comentário não ajudou em nada e mandou um e-mail inútil para 99 pessoas

Ei, você não obtém nenhum resultado a menos que tente, certo?

Senti muita falta dele inicialmente e, embora fosse muito conveniente tê-lo, o 'diff explorer' (terceiro ícone no menu vertical) é realmente poderoso e muito útil

+1
Seria incrível se isso implementado wooow ...!

Eu escrevi uma tarefa gulp que deve simplificar a instalação do hack (somente VS Code 1.15).

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

PS Ainda não testado em todas as plataformas, gostaria que alguém tentasse no OSX.

@ karabaja4 Não parece que o seu 'hack' seja tão complicado de implementar no próprio vscode. Como parece que os desenvolvedores do vscode não estão corrigindo esse problema tão cedo, talvez você possa criar uma solicitação de pull?

@ karabaja4 Obrigado por isso! Trabalhando para mim no macOS Sierra, VSCode 1.15.1.

@ karabaja4 Obrigado! Trabalhando aqui no Fedora 26, VSCode 1.15.0. Aquele por si só tornou a mudança do Atom muito mais conveniente.

@ karabaja4 +1 Obrigado !! Trabalhando para mim no Ubuntu 14.04 64, VSCode 1.15.1 (instalação manual)

+1

@ karabaja4 +1 Isso é incrível.

+1

@matti mais um

_Enviado do meu HTC MSM8996 para arm64 usando FastHub _

@ibrokemypie menos dois

Enviado do meu HTC MKB826262 para arm32 usando Lolbug

Alguma notícia sobre esse recurso?

+1

+1

+1

@ karabaja4 OBRIGADO man = D <3

+1

Uau, isso deveria ter sido implementado há dois anos

@eosrei +1

+1

+1
Vamos enfrentar a realidade; Eu amo VSCode, mas a guia Git é realmente uma merda

@ karabaja4 Oi, 1.16 acabou de sair, você pode portar seu hack neste lançamento? Obrigado.

EDIT: Funciona com 1.16, mas não ao usar espaços de trabalho multi-root.

@ karabaja4 👍

@ karabaja4 acabou de fazer meu dia. Obrigado cara!

+1

+1

Um comentário +1 deve ser um banimento automático dos problemas do GitHub ...

Seria melhor se o GitHub apenas analisasse as mensagens +1 e as substituísse automaticamente por uma reação de emoji com o polegar para cima à postagem original.

@ karabaja4 seu hack roda no OSX 10.12.6 - incrível! Obrigada.

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

A única coisa que recebo agora é uma mensagem de Aviso na inicialização. Felizmente, é apenas um aviso.

VSCode versão 1.16.0

+1

Existe uma razão para que isso ainda não tenha sido implementado ou há algum cronograma quando este recurso será adicionado?

Ontem, voltei ao Atom por uma hora para usar sua última atualização de ide e pensei que minha vida é tão fácil com arquivos coloridos na visualização em árvore de arquivos.

Edit: Acabei de encontrar uma solução alternativa. Adicionar uma linha a um dos arquivos de código vs (<1min de esforço) funciona perfeitamente! https://github.com/karabaja4/vscode-explorer-git-status

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

Você já viu que poderia usar a reação emoji em vez de postar +1 ?

Cada vez que postamos comentários no github, todos os assinantes do tópico recebem notificações e alguns usuários recebem emails também. É meio frustrado ler um e-mail escrito: +1 e você pode ver nesses comentários, há muitos de: -1 :.

A comunidade agradece se todos começarmos a usar as reações:
https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments

Peço desculpas por qualquer ofensa com esta informação e pelos outros que receberam esta notificação.

Eu tinha lido em outros tópicos que a Microsoft classificou a prioridade de um recurso pelo número de comentários +1. Peço desculpas se entendi errado e não é de forma alguma como um recurso é classificado. Eu removi meu comentário. De qualquer forma, o que há com a atitude agressiva mano? Você poderia ter apontado a mesma coisa com um tom melhor @leocaseiro

Saúde.

Olá @aecorredor , Peço desculpas se
Não sou um falante nativo de inglês e talvez uma das minhas expressões traduzidas soou mal. Por favor, ajude-me a melhorar a descrição desse comentário. Devo substituir a palavra irritante? inútil? Obrigado.

PS: Fico feliz que você editou o mundo que li no meu e-mail, porque posso ter soado rude, mas nunca foi minha intenção ofender ninguém.

Atualização: substituí meu comentário anterior, por favor me avise se soa melhor. Obrigado

Ei @leocaseiro ,

Desculpe por escrever esse palavrão em primeiro lugar. Eu realmente percebi
que uma barreira de idioma era provavelmente o que estava causando a confusão. Mas
sim, eu substituiria essas duas palavras por algo mais na linha de:
"Por favor, todos nós estamos tentando melhorar a experiência geral do github para
questões abertas / solicitações de recursos, e seria bom se as pessoas começassem a usar
reações de emoji em vez de comentários como "+1", que apenas criam
sobrecarga desnecessária na discussão e acionar e-mails que não são realmente
contribuindo de forma significativa. Por favor, consulte este link para ver como
As reações de emoji funcionam: {Link here}

Saúde e sem ressentimentos.

Bests.

Na segunda-feira, 18 de setembro de 2017 às 23h44, Leo Caseiro [email protected]
escreveu:

Olá @aecorredor https://github.com/aecorredor , peço desculpas se soou
grosseiro.
Eu não sou um falante nativo de inglês e talvez um dos meus traduzidos
expressões pareciam ruins. Por favor, ajude-me a melhorar a descrição para
esse comentário. Devo substituir a palavra irritante? inútil? Obrigado.

PS: Estou feliz que você editou o mundo que li no meu e-mail, porque posso
soou rude, mas nunca foi minha intenção ofender ninguém.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/178#issuecomment-330420547 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AIsVa9fgWXPMFBgkZdHjQHKhUEDJb8Bmks5sjziWgaJpZM4GlYyH
.

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

Use uma reação no lugar de um comentário "+1".

+1

Eu realmente esperava que o número de + 1s diminuísse após os comentários anteriores, mas, de repente, outro +1 apareceu 😁.

É uma pena, porque os programadores geralmente culpam os usuários por não lerem mensagens de erro, mas não conseguem ler alguns comentários ou instruções.

Talvez valesse a pena colocar algo no README.md para pedir aos usuários que usassem reações em vez de comentar com +1? Talvez em CONTRIBUTING.md esteja um pouco escondido.

Não sei, acho que vou apenas cancelar a assinatura e esperar pelas notas de lançamento quando estiver pronto.

Eu criei um Gist que cuida disso. A correção de @ karabaja4 não @dseipp que nunca foi mesclado. Ainda havia algo errado com seu PR (acho que falta suporte encenado?), Então eu consertei.

Então, se você gostaria que isso funcionasse muito melhor, verifique minha essência: https://gist.github.com/WadeShuler/1637073371ad126779076344c34278f3

@ikatyang : desculpe, isso significa que esse recurso será lançado em outubro (2017) ..?

@nkkollaw o link era deste comentário: https://github.com/Microsoft/vscode/issues/34160#issuecomment -331066864

O comentário estava apenas pedindo para discutir coisas relacionadas a esse problema aqui, e não no "Plano de Iteração" (e pedindo para discuti-los em inglês).

Ah, entendi @tiangolo , obrigado.

Tentarei aguentar o Atom até que haja uma API para implementar essa funcionalidade (desculpe, não sou bom o suficiente para ajudar nisso).

estou trabalhando para fazer a atualização dentro do próprio projeto.
Por enquanto, fiz uma prova de conceito que está funcionando, mas não passei no tslint, pois ainda preciso entender as camadas para colocar tudo no lugar certo.
Vou colocar alguma atualização aqui, e se alguém quiser me ajudar, colocarei o link para minha solicitação de pull mais tarde, então você é bem-vindo para ajudar.

Planejado para a iteração de outubro de 2017 !! 👍

Temos uma primeira versão disso. Todos tenham a certeza de que isso acontecerá em outubro.

Mais um pouco de informação:

• As cores serão definidas nos temas, o que significa que podem ser personalizadas de acordo com o seu gosto
• Haverá uma configuração para ativar / desativar este
• Isso não é exclusivo para o controle de versão. Também estamos procurando destacar erros / avisos no explorador de arquivos (consulte # 782) e estamos pensando em expor isso aos autores da extensão.

Perguntas abertas:

• É suficiente usar apenas uma cor? Deve haver também uma dica textual e / ou ícone?
• Que status de criança um pai deve escolher? Isso deve ser importante? Isso é fácil com erros e avisos, mas o que é mais importante: um arquivo alterado, um não rastreado ou um ignorado?
• Devemos mostrar essas decorações de arquivo também no balde "Abrir editores" e / ou no seletor de arquivos, etc.?

Vou manter este problema atualizado enquanto as coisas acontecem. Como sempre, use emoções em vez de comentários "+1". Obrigado e feliz codificação!

Pessoalmente, o que vejo na imagem acima é suficiente. Parece ótimo e obrigado!

Parece não ter os arquivos ignorados por .gitignore em cinza escuro?

Você não altera a cor (cinza) de uma pasta pai para apenas um arquivo ignorado dentro. Você só o cinza SE a própria pasta for ignorada. Por favor, veja meu comentário / corrija alguns comentários. Faz o Git despejar os status e detectar se é um diretório ou um arquivo. Simplesmente adicionar classes aos arquivos / pastas na árvore de arquivos funcionaria ... Como “git-status-modificado” ou “git-status-added”. Então, os temas podem fazer sua mágica.

Seria bom se vocês pudessem nos deixar ver o que estão fazendo, para que possamos brincar com isso e criar PRs. Honestamente, se for confuso, as pessoas provavelmente deixarão de usar o Code se uma solução viável não puder ser alcançada em um tempo razoável. Muitas pessoas (inclusive eu) deixaram o Atom por problemas semelhantes.

Também acho que se houver erros, talvez use um ponto antes ou depois do nome do arquivo na árvore. Isso seria discreto, permitiria que os temas os definissem e não interferiria no realce de cores do Git.

Sim, isso DEVE ser aberto aos desenvolvedores de extensões! Já deveria ter sido feito. Por que não desejaríamos ter controle sobre a árvore de arquivos para fazer extensões legais ou consertar coisas que vocês não fizeram?

Parece perder os arquivos ignorados por .gitignore em cinza escuro?

Claro, é um trabalho em andamento e as coisas acontecem uma de cada vez. Arquivos ignorados virão, também em outubro.

Seria bom se vocês pudessem nos deixar ver o que estão fazendo, para que possamos brincar com isso e criar PRs.

Claro, está tudo no ramo joh/feco . Há um novo serviço de decoração que usa fornecedores para os dados reais. No lado do consumo está o rótulo do arquivo que usamos para renderizar os nomes dos arquivos

Você não altera a cor (cinza) de uma pasta pai para apenas um arquivo ignorado dentro. Você só o cinza SE a própria pasta for ignorada. Por favor, veja meu comentário / corrija alguns comentários.

Acho que "arquivos ignorados e seus filhos (se houver) estão esmaecidos" é bastante claro.

@nkkollaw Do que você está falando ?!

Em @jrieken disse:

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

Ele indicou um arquivo ignorado possivelmente influenciando o status das pastas pai, o que não deveria!

Sua mensagem passivo-agressiva está apenas obstruindo esta discussão com mensagens inúteis ...

@WadeShuler : Não tenho ideia do que _você_ está falando.

Eu apenas apontei que os arquivos ignorados e seus filhos deveriam estar esmaecidos, e isso é bastante claro que esta definição não pede que os pais de arquivos ignorados fiquem esmaecidos.

Quanto a:

Sua mensagem passivo-agressiva está apenas obstruindo esta discussão com mensagens inúteis ...

Não tenho ideia de como minha mensagem foi passivo-agressiva - acho que você não sabe o que significa - mas é você quem está obstruindo a discussão, já que é o único que comentou depois da minha mensagem.

Esquisito.

nossa .. boa ideia! eu gosto disso!

Eu gostaria de ter o xcode como uma dica textual de um caractere na coluna da direita. Facilita a filtragem / acompanhamento visual dos arquivos.

@nkkollaw eu disse:

Você não altera a cor (cinza) de uma pasta pai para apenas um arquivo ignorado dentro. Você só o cinza SE a própria pasta for ignorada.

Claramente, estou falando sobre pastas pai, não filhos. Aqui, eu desenhei uma imagem para você:

Aqui está .gitignore no diretório pai, web para referência:

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

Minha mensagem foi uma resposta à resposta de @jrieken do WIP, aqui , onde ele diz:

Que status de criança um pai deve escolher? Isso deve ser importante? Isso é fácil com erros e avisos, mas o que é mais importante: um arquivo alterado, um não rastreado ou um ignorado?

Indica que o pai de um arquivo / pasta "ignorado" pode ter um status, o que não é verdade. Daí minha resposta. Você está confundindo o que vê visualmente, em comparação com o que o Git realmente usa para sua lista de ignorados

➜  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 significa que está definido em .gitignore com uma regra especial, daí porque não é apenas backend/web/assets/ e é especificamente os diretórios de ativos nomeados aleatoriamente. Você não especifica todo e qualquer arquivo ignorado ao lidar com um diretório onde seu conteúdo é ignorado. Como os diretórios vendor ou node_modules . Eles têm apenas uma entrada na entrada git status ignorada.

Na árvore de arquivos, você precisa adicionar uma classe de git-status-ignored a TODOS os elementos (arquivos e pastas) que começam com backend/web/assets/6f57f06b/ .

O CSS para corresponder à pasta da árvore de arquivos backend/web/assets/6f57f06b/ é assim (atualmente leva 2 regras!):

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

E

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

Aviso: na 1ª regra, combinamos o título com um sinal = apenas, exatamente! Na 2ª regra, combinamos todos os títulos com ^= , portanto, o início da string, combinando tudo mais profundo do que isso também (todos os filhos).

Para corresponder a um diretório, são necessárias 2 regras CSS. Então eu acho que enquanto fazemos isso, devemos ir em frente e fazer title no elemento HTML para diretórios, para incluir uma barra final. Você pode ver do que estou falando nesta captura de tela:

Sim, seu comentário foi passivo-agressivo, já que você estava sendo rude / sarcástico / desagradável sem realmente dizer as palavras. Além disso, você estava errado. Ninguém disse nada sobre crianças, e nem é sobre isso que estávamos falando.

@jrieken
A forma como minha configuração do Atom funciona: "editado" tem precedência sobre "adicionado". Excluir um arquivo não mostra nenhum status. Não há status para "encenado". Acho que outras pessoas deveriam verificar a configuração do Atom e ver se isso é verdade para eles também, e se não é apenas a minha configuração. Seria bom adicionar código para cada situação e deixar o usuário editá-lo para funcionar como quiser.

Talvez adicionar várias classes, de forma que os diretórios pais em toda a árvore tenham "git-status-added" e "git status-modificado". Talvez até inclua "git-status-deleted" se algo foi excluído abaixo dele.

Em seguida, é só usar css para combiná-los. Se você quiser uma cor diferente para .git-status-added.git-status-modified , você pode criar uma fonte laranja com um sublinhado verde (laranja para modificado, verde para adicionado). Se ele tivesse apenas a classe .git-status-added , torne a fonte verde.

Realmente não importaria depois de adicionar classes a eles, todos podem preparar algum CSS da maneira que quiserem. Você gostaria de ter um chiqueiro padrão "muito bom" pronto para uso.

Vou puxar esse galho quando tiver algum tempo e dar uma olhada.

Como lidar com erros de lint E status de git?

O Atom coloca uma linha vermelha embaralhada sob o nome do arquivo, como você pode ver aqui:

Acho que devemos adicionar uma classe como lint-error ao mesmo elemento que o status git, que nós (e temas) podemos substituir por meio de nossas próprias folhas de estilo.

Portanto, a div para o mesmo elemento na árvore de arquivos que usei como exemplo acima (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>

Ficaria mais ou menos assim, quando aplicamos um status git de git-status-edited e 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>

Então, poderíamos fazer a correspondência 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;
}

Vocês têm um Slack? Existem muitos arquivos editados no commit. Estou procurando exatamente onde você está aplicando a cor de status git à árvore de arquivos. Está em /extensions/git/src/repository.ts ?

Obrigado a todos e obrigado por esclarecer as regras de alterações, arquivos não rastreados e ignorados. Os insiders do amanhã virão com uma versão inicial disso.

Um par de coisas

• Por padrão, há uma combinação de cor e bagde.
  
  
  
  • habilitar / desabilitar ícones com: "explorer.decorations.badges": true|false
  
  
  • habilitar / desabilitar cores com "explorer.decorations.colors": true|false
  
  
• As cores são mostradas na árvore de arquivos, na seção de editores abertos e no viewlet SCM
• Existem três cores para começar. Você pode personalizá-los na configuração workbench.colorCustomizations . As cores são gitDecoration.modifiedResourceForeground ,
  gitDecoration.deletedResourceForeground ,
  gitDecoration.untrackedResourceForeground ,
  gitDecoration.ignoredResourceForeground , e
  gitDecoration.conflictingResourceForeground
• Observe que os nomes das configurações, etc., provavelmente serão alterados, novas configurações podem ser adicionadas, outras configurações podem ser removidas novamente.

Para sua informação - editado para refletir as alterações feitas após a postagem inicial

Acho melhor não aplicar os ícones do lado direito aos diretórios pais. Pode haver pelo menos uma opção.

Isso parece ter sido atualizado na versão interna com scm.fileDecorations.useIcons e scm.fileDecorations.useColors sendo substituídos por scm.fileDecorations.enabled que fornece os ícones e as cores.

Eu gostaria de ter apenas as cores, mas não os ícones. Ou seja, o comportamento "antigo" de scm.fileDecorations.useIcons : false e scm.fileDecorations.useColors : true

Eu tentei fazer experiências com explorer.decorations.badges e explorer.decorations.colors mas eles parecem não surtir efeito.

EDITAR:
Estou executando a versão 1.18 interna, Commit f1ee80be081b0d ... no Windows 10
(Seria bom se o texto na caixa de diálogo sobre pudesse ser destacado para que você pudesse copiar)

Obrigado por colocar isso junto @jrieken !

Tive algumas ideias:

• parece que a cor selecionada ainda é o cinza antigo em vez da cor de status
• concordou com a opção de ter ícones ou não (por @FredrikFolkesson )
• com os ícones aparecendo, se a cor modificada / atualizada for clara, o 'M' ou 'U' deve ser escuro (ou vice-versa) para que o contraste esteja lá e seja mais fácil de ler.

Ansioso para não ter que atualizar o arquivo main.js com cada construção para obter as cores !!!

Problema menor (usei os insiders mais recentes em 16 de outubro) para relatar, @jrieken : A cor do nome do arquivo modificado na árvore do projeto não é mostrada se este arquivo estiver selecionado no momento. A expectativa aqui é que não importa se o arquivo está selecionado ou não na árvore do projeto, a cor deve ser a mesma (denotando o arquivo modificado).

Outro problema que gostaria de abordar é o mesmo código de cores não apenas para a árvore do projeto, mas também para a seção de editores abertos. Atualmente, não há como ver na seção de editores abertos quais arquivos foram modificados e quais não foram. A capacidade de descobrir rapidamente quais editores são para arquivos modificados é MUITO conveniente, de modo que se possa pular entre os arquivos que ele / ela modifica rapidamente e não há necessidade de tentar lembrar os nomes dos arquivos modificados atualmente.

Isso seria um ótimo recurso. Novo no VSC da Atom e sinto muitas saudades.

Também movido do Atom e também sem esse recurso. Quando é agendado o lançamento com este recurso?

Da mesma forma, é mais importante porque os arquivos gitignored são muito proeminentes na lista e se misturam com tudo ...

Olá, acho que também precisamos de uma chave de cor para alterar a cor do primeiro plano dos emblemas (# 36246)

Obrigado a todos pelo feedback contínuo. Eu atualizei meu comentário resumido inicial para refletir as mudanças recentes. Também me certifiquei de que as alterações nas configurações sejam refletidas sem recarregar e que a cor de status ganhe sobre a cor de seleção.

Por padrão, ainda usamos a cor e um emblema, principalmente por dois motivos: Nem todo mundo sabe imediatamente o que a cor significa e ter o emblema (com sua dica) pode tornar isso autoexplicativo. Em segundo lugar, há pessoas, na verdade como eu, tendo dificuldade em diferenciar essas cores e o emblema foi feito para tornar isso um pouco mais acessível.

@jrieken Você pode me dizer se as classes CSS estão sendo aplicadas aos elementos do explorador de árvore de arquivos à esquerda? Isso daria a melhor capacidade de expansão e tornaria mais fácil para os desenvolvedores de temas, e para nós, pessoalmente, personalizar e substituir as cores.

Por exemplo: quando suas novas correções de código marcam um arquivo ou pasta como adicionado, ele deve adicionar uma classe como git-status-added . Então, podemos direcionar se, por meio de nossas folhas de estilo, podemos personalizar as cores e não ficar presos ao que você nos fornece fora da caixa.

@WadeShuler Nossas personalizações de tema / cor não funcionam com css diretamente, mas com algo que chamamos de cores de tema . É uma indireção, dar nomes a certas coisas como editorLineNumber.foreground é o nome da cor do primeiro plano para os números das linhas. Os temas atribuem cores a esses nomes e o editor coleta esses valores ao renderizar. Verifique isso para obter mais informações sobre ele: https://code.visualstudio.com/docs/getstarted/theme-color-reference

Com os próximos insiders, provavelmente amanhã, 19, haverá renderização especial para arquivos ignorados ( git.color.ignored ) e as cores / emblemas serão mostrados na seção "Editores Abertos". Eu atualizei https://github.com/Microsoft/vscode/issues/178#issuecomment -335511695 de acordo.

@jrieken Awesome! Que tal uma chave de cor para o primeiro plano dos emblemas do git?
https://github.com/Microsoft/vscode/issues/178#issuecomment -336904514

Muito bom trabalho! É ótimo ver esse recurso chegando ao vscode.

Na implementação atual, os arquivos modificados em um submódulo ainda não estão marcados corretamente como sendo modificados.

No exemplo a seguir:

O repositório principal inclui um submódulo em src/components/ . Vários arquivos foram modificados no submódulo. vscode relata corretamente que src/components/ foi modificado, mas não está indicando quais mudanças foram feitas no submódulo.

O Atom identifica corretamente os arquivos modificados:

Este problema provavelmente está relacionado a https://github.com/Microsoft/vscode/issues/7829

@jrieken Awesome! Que tal uma chave de cor para o primeiro plano dos emblemas do git?

@equinusocio Não se preocupe, isso vai acontecer, mas é preciso pensar um pouco. Está agendado para outubro

@jrieken Obrigado !. Eu perdi algo .. ícones de pasta também tem a cor modificada / adicionada? Existe uma nova chave para adicionar ao tema do ícone para definir ícones diferentes para pastas quando o git é editado / modificado?

@jrieken - Problemas em 1.18. Eu quero dizer obrigado pelo seu trabalho até agora. Acabei de testar os Insiders v1.18. Eu dei uma olhada rápida no tópico acima, então perdoe se você já tem algo em andamento para 1.19 para resolver o que eu menciono abaixo.

1) O status "adicionado" na árvore de arquivos parece "atualizado e não mesclado" com o emblema "U". Os arquivos adicionados devem ter um emblema "A".

2) Não há opção de cor para git.color.added

3) Não há opção de cor para git.color.ignored .

4) (Glitch) Ele trata os arquivos "adicionados" como "não rastreados". Eu inspecionei um arquivo "adicionado", e parece que no html, ele acha que não está rastreado. (o título span diz "não rastreado" e a classe é monaco-decorations-style-32 , o ícone "U"). Isso é evidente ao alterar a cor em workbench.colorCustomizations para git.color.untracked , pois controla os supostos arquivos "adicionados".

5) Suporte ao status "R", para "renomeado" ou movido, adicione um emblema "R" e adicione a configuração git.color.renamed .

Obrigado, estou ansioso para experimentar o 1.19 👍

@danjjl Há um PR pendente para o # 7829 Com isso aplicado, os submódulos do git obtêm a coloração.

Há um problema potencial, em que se o submódulo for alterado, não sei se (o diretório que é a raiz do submódulo) será tratado como a cor do status do diretório no repositório git principal, ou um diferente cor com base nos arquivos contidos.

Ou seja, não sei se a cor do diretório do submódulo será baseada em 'git status' no diretório pai, ou no submódulo. Pode não importar de qualquer maneira.

@jrieken Você tem um grupo do Slack ou algum outro lugar para discutir esse assunto? Posso ajudar :) Consegui extrair, desenvolver e depurar as alterações atuais do branch master. Eu consertei os arquivos "adicionados" que mostravam "U" e até adicionei o suporte "encenado". Como foi minha primeira vez no projeto, estou redefinindo para master e fazendo tudo de novo. Fiz um monte de mudanças e quero entrar como um cirurgião e não como uma arma nuclear.

Por que existem verificações em raw.x + raw.y seguidas por verificações em raw.x depois em raw.y ? Parece que ele corresponde a 2 status diferentes.

Por que existem 2 constantes de status para ADDED / INDEX_ADDED , MODIFIED / INDEX_MODIFIED e alguns outros? Eu entendo todos os diferentes status do git, mas faria sentido lidar com isso para o usuário final, não a nomeação dos status do Git. ADDED deve ser usado para o que você tem agora como UNTRACKED para então ter um código de configuração de git.color.added . Acho que algumas dessas constantes de status são duplicadas e devem ser simplificadas e limpas.

Um status git de _M <- underscore = space / nothing, corresponderia a raw.y e vocês o têm como INDEX_MODIFIED . Isso está incorreto, o status onde x = nada ey = M representa staged .

Por algum motivo, às vezes aleatoriamente, parece não refletir as mudanças. Além disso, parece que as mudanças de status do git estão varrendo recursivamente de cima para baixo. Se você tem um projeto grande, pode observar o status "ignorado" fluir para baixo em suas pastas / arquivos. Para acelerar, navegar mais fundo, parecia chutá-lo para aquele diretório e acinzentá-los. - Este processo está deixando o sistema / VSCode muito lento? Alguém o comparou? Realmente não há necessidade de percorrer cada arquivo / pasta quando o pai é ignorado. Os filhos devem obter seus status de seus pais. - Se você tem 5.000 arquivos ignored mas todos em 2 diretórios (ou seja: node_modules, vendor), então não devemos processar 5.000 arquivos, apenas 2 diretórios que controlam a aparência de seus filhos.

Vou refazer minhas alterações mais tarde hoje e emitir um PR.

Obrigado novamente por seu trabalho. Eu só estou tentando ajudar em vez de insistir em você, já que eu posso realmente fazer isso lol 👍

@WadeShuler eu posso responder algumas https://git-scm.com/docs/git-status , especialmente a tabela "Significado XY"
(EDITAR: uau, a formatação estava ruim. Basta ir para o original. É uma tabela em vermelho na metade do caminho.)
Isso é claramente o que eles estão usando para tudo isso.

E acho que você está enganado no caso _M, que corresponderia a MODIFIED, Index unmodified (ou seja, não encenado). A menos, é claro, que você esteja vendo uma duplicata desse código em outro lugar.

@petkahl Obrigado, estou familiarizado com o Git Status Short Format . Usei-o semanas atrás para corrigir meu status vsc git para adicionar status Git básicos até que isso seja resolvido oficialmente.

É possível (de alguma forma) obter _M (sublinhado = espaço). Não tenho certeza de como, por que, quando .. Recebi isso hoje mais cedo (bem como algumas semanas atrás, quando trabalhava em meu Síntese):

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

Agora, algumas horas depois, eu o executo e obtenho "A". Não sei o que mudou desde então ..

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

Quando eu estava fazendo pesquisas para meu Gist, acho que concluí que é possível obter "A_" e "_M" para encenado. Eu também encontrei um site que quebrou o status muito mais claro do que os documentos do git-status, eu simplesmente não consigo encontrar de novo lol.

Você também pode obter "AM" para um arquivo testado e modificado. Crie um novo arquivo vazio, adicione-o (prepare-o), edite o arquivo e salve-o, verifique o status:

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

Portanto, este deve ter 2 emblemas, "[S] [M]"? Prefiro saber quais arquivos preparei. É útil na colheita de cereja. Pode ser útil ainda ver se você modificou um arquivo testado. Deve ter pelo menos um crachá encenado.

@WadeShuler eu posso obter _M consistentemente, ao comprometer e modificar. O que significa que ele não foi alterado (_ = espaço) no índice, mas modificado na árvore de trabalho.
tão:
Criar arquivo: ??
git add file A_
git commit (não em status, mas o equivalente a espaço)
modifique o arquivo: _M
git add file M_
modifique-o novamente: MM

Eu realmente não tenho uma opinião sobre os emblemas quando há dois. Eu nunca faço check-in sem olhar para a janela de status, que divide tudo claramente, assim como faz o status regular do git. Talvez apenas uma configuração que permite escolher qual tem prioridade? Eu podia ver argumentos para ambos. Ou dois emblemas, eu acho. Seria o mesmo para a coloração?

Eu adicionei suporte para Staged . Você pode ver as mudanças aqui: WadeShuler / vscode: gitstatus-fix . Também fiz alguns dos emblemas na guia Status do Git parecerem um pouco melhores, tornando-os um pouco maiores.

Por alguma razão, ele removeu o escurecimento / ignorar do diretório vendor , mas seu conteúdo ainda está esmaecido e ignorado. Não entendo por que minha modificação simples parou de escurecer o diretório vendor ? Esse é o único problema com o que acabei de fazer e por que ainda não fiz uma RP ...

Se as cores / ícones do arquivo testado forem incluídos, isso definitivamente deve ser opcional. Pessoalmente, prefiro não ver encenado em minha lista como uma cor diferente da cor original nova / modificada.

Depois de começar a incluir encenado, pode ficar complicado rapidamente, pois existe a possibilidade de incluir todas as combinações e permutação de novo / novo encenado / modificado / encenado modificado / modificado-encenado-modificado / novo-encenado-modificado, etc. , o que levará a uma enorme matriz de cores e confusão.

Eu voto para não complicarmos demais o assunto.

Eu concordo @dseipp. Essa é a razão exata pela qual eu não mesclei o suporte para arquivos testados em meu hack inicial quando o fiz, uma vez que não vi nenhuma utilidade para os arquivos testados serem coloridos.

O objetivo do realce de cor é permitir que eu encontre arquivos novos / modificados rapidamente no explorador de arquivos. Se eu preparar alguns arquivos, geralmente é antes do commit ou se eu não os tiver feito de outra forma, então não tenho nenhuma utilidade para eles serem coloridos normalmente.

Se adicionarmos cor para cada tipo possível de status git, o explorador de arquivos começará a se parecer com uma árvore de natal e será muito confuso ver o que realmente está acontecendo.

@jrieken Mais um relatório de bug, acontece nos insiders mais recentes:

• Versão do VSCode: Code - Insiders 1.18.0-insider (82dcf9835265cd0a45ec135587ae2a82673f1c8f, 2017-10-20T04: 24: 25.632Z)
• Versão do sistema operacional: Windows_NT x64 10.0.15063

Basicamente, o VS Code "esquece" de vez em quando que alguns arquivos são modificados e precisam ser coloridos de acordo. Por exemplo, tenho 6 arquivos modificados no momento. O código VS (corretamente) mostra o número "6" no botão git. Mas, na árvore de arquivos do projeto, vejo apenas UM arquivo em amarelo, os outros cinco arquivos parecem não ter sido modificados. Curiosamente, todos os 6 arquivos estão devidamente coloridos na seção de editores aberta.

@dseipp Pode ser opcional. No entanto, você nunca verá a cor "encenada" antes de preparar os arquivos ... Então, ela nem é vista 99% do tempo e não deve incomodar ninguém.

@ karabaja4 Não concordo que não tenha utilidade. Você afirmou que nunca usa / percebe / precisa de coloração encenada ...

O objetivo do realce de cor é permitir que eu encontre arquivos novos / modificados rapidamente no explorador de arquivos. Se eu preparar alguns arquivos, geralmente é antes do commit ou se eu não os tiver feito de outra forma, então não tenho nenhuma utilidade para eles serem coloridos normalmente.

Portanto, mesmo se esse recurso for adicionado, não deve incomodá-lo ...

Ser capaz de ver os arquivos encenados ajuda a escolher o que você está prestes a enviar. Se tivermos 100 arquivos alterados, então precisamos agrupá-los, podemos vasculhar a árvore de arquivos e ver facilmente o que foi testado e capturar os que perdemos, para garantir que estejam no mesmo commit.

Quantas vezes você comprometeu um punhado de arquivos e depois percebeu que perdeu um? Você então tem 2 opções, modifique seu último commit para incluir os arquivos perdidos ou faça um novo commit. Ao trabalhar com equipes, é mais limpo e menos confuso tê-los no mesmo commit.

No ponto de teste, não importa se o arquivo foi adicionado, modificado ou qualquer outra coisa.

Para ser honesto, a maneira como o Visual Studio Code lida com o Git é complicada e cheia de erros. Árvores de arquivos grandes, você pode literalmente assistir a coloração pingar pelos arquivos / pastas. Ele descarta a coloração aleatoriamente ...

Acho que todo o suporte do Git precisa ser reescrito do zero.

Também gostaria de expressar meu apoio por ter encenado a coloração de arquivos (opcional, desde que eu possa habilitá-lo).

Aqui está meu fluxo de trabalho: eu começo a trabalhar em algum recurso / correção de bug, coloco-o no estado "OK", o que significa que o código mais ou menos funciona, mas requer alguns ajustes / ajustes / limpeza ou refatoração. Nesse momento, realizo minhas mudanças. Em seguida, execute a limpeza e a refatoração. Se a refatoração falhar ou se tornar muito complicada, eu simplesmente volto ao estado de teste.

Ter a capacidade de ver quais arquivos estou modificando no momento é muito benéfico, e quando eu preparo as alterações, não quero perder todas as informações e chegar à árvore simples, sem cores.

@vvs Concordo em relação aos arquivos

O Maybe Staged pode manter as mesmas cores, mas basta adicionar algum tipo de destaque ou negrito para dar contraste.

Pode ser útil olhar para a técnica anterior ... não me lembro de ter visto o indicador em estágios, mas talvez os tempos tenham mudado

Os ícones no explorador de arquivos para arquivos modificados / não testados / ... são realmente necessários? Tenho alguns problemas de atenção, então as cores e os ícones me distraem facilmente. Não poderia ser opcional e desabilitado por padrão? Eu sou o único que se distrai com eles?

Do ponto de vista da experiência do usuário, às vezes menos é mais, e muitos não se importarão em procurar a opção de desabilitar essas coisas e continuarão sofrendo ou até mesmo trocarão de editores. Eu acho que seria uma boa coisa pensar nisso e decidir se isso é realmente necessário para uma UX melhor (o que eu presumo que seja o objetivo desses ícones).

* Não tive tempo de ler todos os comentários sobre este assunto, então me diga se o que estou perguntando é algo que já foi discutido e tomarei meu tempo para ler tudo o mais rápido possível para entrar em contato com o que foi dito. Obrigado.

Eu acho que seria uma boa coisa pensar nisso e decidir se isso é realmente necessário para uma UX melhor (o que eu presumo que seja o objetivo desses ícones).

https://github.com/Microsoft/vscode/issues/178#issuecomment -336960308 é por isso que temos cores e emblemas por padrão. Concordou que torna a IU um pouco mais confusa, aberta para sugestões que são acessíveis / inclusivas, mas também elegantes e limpas.

@jrieken Obrigado! Você pode me indicar o commit que apresentou os emblemas? Vou tentar encontrar algo que seja benéfico para os dois problemas (dificuldade em ver as cores ou não saber para que servem e problemas com distração).

@jrieken Vamos pegar uma página do Xcode e tornar os emblemas mais sutis.

Os emblemas são úteis para dar dicas aos novatos, mas se tornam desordenados depois que as cores são aprendidas.

Para tirar a bicicleta extra, eu prefiro os emblemas coloridos em git.color.ignored (_esquerda_ acima) porque eles têm a mesma importância visual. Ou seja, desapareça, mas não desapareça no caso de eu precisar de você.

Se implementarmos emblemas sutis, os emblemas da barra lateral do Source Control devem ser atualizados para consistência.

Seja qual for a direção da discussão do emblema, o design do emblema poderia pelo menos ser consistente com aqueles na barra lateral do Git? Parece um pouco desconexo ter um design para a barra lateral do Explorer e um diferente para a barra lateral do Git.

Eu gosto da sugestão de

Se implementarmos emblemas sutis, os emblemas da barra lateral do Source Control devem ser atualizados para consistência.

Isso vai acontecer, está nos meus planos para outubro.

Atualizei https://github.com/Microsoft/vscode/issues/178#issuecomment -335511695 com as capturas de tela e nomes de cores mais recentes. Além disso, com o insider de amanhã, mostraremos os mesmos emblemas no viewlet SCM, mas sem rótulos coloridos. Igual a

Está com uma aparência melhor @jrieken - Obrigado por seu esforço contínuo. Acho que os emblemas parecem muito melhores!

Porém, o emblema deve ser U ? Acho que a comunidade deveria pesar. O U me faz pensar primeiro updated . Eu sei que é untracked na terminologia Git, mas acho que A é mais adequado, especialmente para aqueles que não estão familiarizados com os termos subjacentes, que U é rastreado. - Eu pessoalmente voto em A adicionado. Como em, ele foi adicionado ao seu repositório.

Então suporte para staged (opcional por meio de configurações) e está bem perto 👍

@WadeShuler , que tal um ponto de interrogação (?) Para não rastreado? Eu não gosto de A porque tem uma conotação diferente para git do que o significado aqui, pelo menos em minha mente.

Edit: Mas concordo que você pode ser confuso.

Acho que ficaria bem com um ponto de interrogação. No entanto, eu não acho que o Código
só suporta Git, não é? Eu não acho que devemos olhar para isso visualmente em
o editor como “Git”, mas mais controle de versão em geral.

Seja qual for o caso, eu realmente não gosto de “U” lol

Na terça-feira, 24 de outubro de 2017 às 14h20 Peter Kahle [email protected]
escreveu:

@WadeShuler https://github.com/wadeshuler , que tal um ponto de interrogação
(?) para não rastreado? Eu não gosto de A, pois tem uma conotação diferente para
git do que o significado aqui, pelo menos em minha mente.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/178#issuecomment-339084261 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AJHVkJJNzw89umFiPB0BmgQAZYJNXTHzks5svip7gaJpZM4GlYyH
.

Muito justo, deveria ser agnóstico. Mas "Desconhecido para o sistema de controle de versão" como um? Faz sentido para mim. Mas N (para Novo) poderia funcionar também, e não consigo pensar em nenhuma sobrecarga para esse, embora tenha certeza de que outra pessoa o fará.

Sim, @jrieken , seus esforços são muito apreciados! Está muito bom! Os emblemas sutis são uma vantagem.

Estou com @WadeShuler e @petkahl sobre o desejo de mudar o U para outra coisa. O 'N' ou '?' trabalhar. No entanto, estou inclinado para o N, pois seria 'N'ew e' M'odified.

Estou ansioso para ver isso acontecendo!

workbench.colorCustomizations.git.color.ignored funcionando para todos?
Estou na 1.18.0-insider última atualização hoje e a cor ignorada ainda não foi escolhida. Além disso, parece que "_deleted_" e "_conflict_" ainda não funcionam ... talvez com a atualização de amanhã,
Mas o que está me incomodando é a cor ignorada. O nome do arquivo parece o mesmo de um arquivo versionado - não modificado, o que significa que nenhuma cor especial foi aplicada a ele.
Nota: O repositório na captura de tela não possui arquivos rastreados de qualquer espécie. Todos os arquivos não são rastreados. Depois de remover "_shared.module.ts_" de .gitignore , ele aparece em marrom (minha configuração de cor não rastreada).

O emblema deveria ser U, entretanto? Acho que a comunidade deve pesar. A U me faz pensar primeiro em atualizado. Eu sei que não é rastreado na terminologia Git

Nós usamos 'U' antes, este não é o assunto certo para discutir o que é melhor, mas acho que os usuários do git conhecem a terminologia e para outros provedores de SCM outras letras / ícones podem / devem ser usados ​​(e é o caso hoje).

Este recurso não foi adicionado, e estou ativo neste tópico desde
começou a avançar. Eu mencionei o emblema “U” desde o início.

Este tópico é sobre como desenvolver e aperfeiçoar todo o recurso, uma vez que
é novo. Se a cor da fonte, o estilo do distintivo e as cores do distintivo são todos aceitáveis
para discutir neste tópico, as cartas também.

Então, onde mais, fora deste tópico, temos usado “U”?

Então, onde mais, fora deste tópico, temos usado “U”?

Verifique stable, não insiders, e o viewlet SCM com git. Ele usa um L para u ntracked arquivos.

@WadeShuler @jrieken O viewlet SCM atual (1.17.2) marca um _arquivo não rastreado_ com um U cinza e um _arquivo adicionado_ com um A verde . git status mostra _arquivos adicionados (preparados )_ em verde ANSI .

Portanto, eu entendo a confusão com um U verde para um _arquivo não rastreado_. Eu também prevejo meus olhos doendo por causa de U verdes misturados com A s

O Atom colore os novos arquivos não rastreados e testados como verdes , e o Xcode marca os arquivos adicionados como A , desde que seja um novo arquivo. Ambos nunca me incomodaram nem um pouco (mas um U verde sim).

Então, eu farei tudo para usar As verdes para novos arquivos não rastreados _e_ testados.

Vamos continuar o 'U' vs 'A' vs '?' discussão em https://github.com/Microsoft/vscode/issues/36912. Obrigado.

Eu concordo. Acho melhor continuar com as letras usadas na interface hoje. Eu também não gosto do 'U', mas acho que isso está um pouco fora do escopo desta solicitação de recurso. Se isso mudou, deve mudar em todo o programa.

OK, este é um tópico enorme e eu só tenho tempo para lê-lo rapidamente, então direi apenas aqui: Espero que haja uma configuração para desabilitar isso. Prefiro todos os nomes de arquivo da mesma cor e quando preciso ver o status deles digito git status . :-)

Este produto está abandonado? Parece ser.

Atualmente, list.activeSelectionForeground parece ter precedência sobre o estilo do git status, então as cores do git status não podem ser vistas no arquivo selecionado. Acho útil ter essa informação, mesmo no arquivo atualmente selecionado. Alguma chance do estilo de status do git ter prioridade quando explorer.decorations.colors for verdadeiro?
Este comportamento foi observado em insiders 1.18 8dfa696.

Atualmente, list.activeSelectionForeground parece ter precedência sobre o estilo do git status, então as cores do git status não podem ser vistas no arquivo selecionado.

Na verdade, o mesmo aqui nos insiders mais recentes (recém-atualizados). Quando clico no nome do arquivo na árvore do projeto, a cor da entrada do arquivo é alterada (digamos, de amarelo / modificado para neutro). Também acho que este é um comportamento bastante confuso. A cor do arquivo não deve mudar quando o usuário clica no arquivo.

Aliás, o mesmo problema com a lista de arquivos abertos, quando você clica no arquivo lá, a cor de status do git é substituída pela cor de seleção neutra.

Aliás, o mesmo problema com a lista de arquivos abertos, quando você clica no arquivo lá, a cor de status do git é substituída pela cor de seleção neutra.

Bem, isso foi feito de propósito porque a cor do primeiro plano da seleção frequentemente entra em conflito com as cores da decoração. Adicionar mais cores, como git.untrackedSelectedForeground e git.untrackedFocusedForeground , não nos pareceu muito atraente. Portanto, deixamos a cor de seleção ganhar quando um item é selecionado e tem foco.

O Atom não parece ter problemas com isso ...

Não há necessidade de novas configurações ... Os temas serão atualizados para acomodar se a cor de fundo do item selecionado interferir. Aqueles que não o fizerem, a comunidade decidirá não usar esses temas.

Não verifiquei, mas espero que os "emblemas" (por exemplo: U, M) ainda não sejam arquivos svg. Eles devem ser apenas texto bruto que pode ser estilizado / colorido.

Honestamente, o VSCode deveria ter usado folhas de estilo para essas coisas, em vez de configurações desajeitadas. Isso complicou um processo bastante simples.

@WadeShuler Há seleção e foco e, como vejo um cursor do editor em sua captura de tela, acredito que seu item está apenas selecionado, não em foco. Na verdade, não vejo diferença no Atom entre selecionado e focado. É assim que funciona no VS Code

selecionado, mas não focado

selecionado e focado

@jrieken Verifiquei duas vezes e, em meu Atom, o selecionado versus o focado produz o mesmo resultado. Ele nunca perde a cor da fonte yellow na janela esquerda do explorador de arquivos. Em sua segunda captura de tela, a cor red foi perdida de test.foo , que é o problema.

Eu tentei os temas Atom padrão escuro e claro, bem como cerca de 3 outros temas. Meu padrão (como você vê no meu SS) é Seti (interface de usuário e tema). Não consigo fazer o Atom remover a cor yellow do explorador de arquivos, não importa o que eu faça. Atom versão 1.21.2.

Selecionado

Selecionado e focado

Pronto para uso, o VS Code deve preservar a cor do status git independentemente dos estados selecionados ou focalizados.

Se o seu problema são os temas, não é o seu problema. Essa é a responsabilidade dos desenvolvedores de tema para atualizar e acomodar.

Em uma observação lateral: eu não verifiquei os insiders mais recentes ou vi o código, mas os arquivos git ignored devem usar opacity não uma cor de fonte, então é sempre x mais escuro do que os arquivos normais, independentemente de sua cor.

@WadeShuler obrigado por seu feedback sobre como os gerentes de tema devem lidar com seus negócios! Como a equipe VSCode ousa fornecer uma API para ajudá-los a fazer isso? Esses desenvolvedores preguiçosos!

@fernandofleury Ninguém disse nada sobre não fornecer aos gerenciadores de tema uma API para gerenciá-lo. Minha postagem não dizia nada do tipo. Portanto, seu comentário sarcástico é simplesmente inválido e injustificado.

@jrieken disse:

Bem, isso foi feito de propósito porque a cor do primeiro plano da seleção frequentemente entra em conflito com as cores da decoração.

Eu disse:

Se o seu problema são os temas, não é o seu problema. Essa é a responsabilidade dos desenvolvedores de tema para atualizar e acomodar.

O problema seria um conflito entre a cor do primeiro plano (na verdade, é uma cor de fundo) do item da árvore de arquivo / pasta (normal, selecionado, focado) e as opções de cor da fonte para os vários status git.

Isso _seria_ responsabilidade dos desenvolvedores de temas. Eles devem escolher as cores do primeiro plano dos itens na árvore e as cores da fonte para os vários status do git para que não entrem em conflito.

Por exemplo: Um desenvolvedor de tema tem ThemeX e sua cor de fonte para os itens na árvore de arquivos do explorer é yellow . Bem, sua cor de fonte padrão entraria em conflito com a cor de status padrão de yellow git. Você não seria capaz de saber quais arquivos foram modificados. Portanto, isso seria responsabilidade dos desenvolvedores do tema! - O mesmo é para a cor de fundo para itens selecionados / selecionados com foco na árvore de arquivos do explorer versus as cores das fontes dos status do git.

Isso está adiado agora?

@IljaDaderko Acho que não, já que aparece na próxima nota de lançamento v1.18 da próxima versão estável. A questão pode ser mais, isso será encerrado ou ainda há mais trabalho a ser feito?

@IljaDaderko VSCode v1.18 já foi lançado e inclui as mudanças discutidas aqui.

As cores de arquivo ignoradas devem fazer parte da atualização v1.18? Os documentos dizem que gitDecoration.ignoredResourceForeground pode ser usado para colorir arquivos ignorados, mas até agora não consegui ver que isso afetaria nada. Coloração modificada / não rastreada funciona muito bem. Este é o Windows 1.18.0 estável.

O mesmo aqui (sobre a cor ignorada). Não tem funcionado para mim também, desde que toda a implementação do Git começou. Usando Insiders.
Tudo o que gitDecoration.ignoredResourceForeground faz é ignorar arquivos ignorados de colorir :)

Está funcionando para mim e parece ESPECTACULAR.

Finalmente está aqui 🥇

@arxpoetica Isto é o que eu recebo:

Como pode funcionar para alguns e não para outros, eu não entendo. É apenas aquela configuração gitDecoration.ignoredResourceForeground
Eu sou o único para quem isso não funciona? Realmente mais ninguém? :) Ah, e @Shurelia
Alguém mais (nós, usuários) realmente testou a configuração da cor ignorada antes de dizer que funciona?

SO: Windows 10 PRO (1709)
VSCode: 1.19.0-insider (recém-atualizado)
O mesmo ocorre no meu laptop de trabalho e no desktop doméstico.

Está no Insiders? Como posso usar?

Parabéns a todos!

@nkkollaw Em ambos 😎 internos e estável (1.18)

@MrCroft Discuta os problemas do git-ignore aqui: https://github.com/Microsoft/vscode/issues/37857

Como enviamos esse recurso em nossa versão estável mais recente, é hora de encerrar e bloquear esse problema. Por favor, crie novos problemas para discussões de tópicos e relatórios de erros. Problemas em torno desta área são marcados com o rótulo file-decorations -label.

A todos, obrigado pelo feedback excelente e contínuo que tornou este recurso o que ele é!

Para resumir e repetir meu comentário anterior .

Um par de coisas

• Por padrão, há uma combinação de cor e bagde.
  
  
  
  • habilitar / desabilitar ícones com: "explorer.decorations.badges": true|false
  
  
  • habilitar / desabilitar cores com "explorer.decorations.colors": true|false
  
  
• As cores são mostradas na árvore de arquivos, na seção de editores abertos e no viewlet SCM
• Existem três cores para começar. Você pode personalizá-los na configuração workbench.colorCustomizations . As cores são gitDecoration.modifiedResourceForeground ,
  gitDecoration.deletedResourceForeground ,
  gitDecoration.untrackedResourceForeground ,
  gitDecoration.ignoredResourceForeground , e
  gitDecoration.conflictingResourceForeground