• 1

Sería genial si esto fuera expuesto como una extensión de alguna manera. Me preocupa que, en algunos casos, el árbol pueda estar un poco contaminado de color y parecerse a un árbol de Navidad. O si no, al menos tienes la opción de activarlo y desactivarlo.

Sí estoy de acuerdo. Creé un problema separado para tener esto expuesto en la API de extensión (ver # 1394).

+1

Me encantaría eso también. La pestaña Git es muy útil, pero esto es para otro propósito: tener colores como en Atom sería muy elogioso para ver de un vistazo qué ha cambiado y dónde (con el color propagándose automáticamente al directorio superior). Esa es probablemente la característica que más extraño de Atom.

Por lo general, no tiene decenas o cientos de archivos modificados sin enviar, por lo que es poco probable que se vea como un árbol de Navidad :)

Así que parece que el PR para esto se cerró. @bpasero @joaomoreno - ¿alguna actualización sobre el estado de este trabajo?

Compruebe esto https://github.com/Microsoft/vscode/pull/8462

Sin actualizaciones...

¡Muchas gracias por su interés en este número! Actualmente está asignado a la cartera de pedidos. Cada mes seleccionamos elementos de la cartera de pedidos para planificar la iteración actual. Consulte https://github.com/Microsoft/vscode/wiki/Issue-Tracking#planning para obtener más información.

Dado que somos un pequeño equipo de desarrolladores, hay un número limitado de solicitudes de funciones y problemas en los que podemos trabajar para un hito. Sin embargo, siempre damos la bienvenida a las solicitudes de extracción y estamos felices de aceptarlas si cumplen con nuestros estándares de calidad.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Deje de escribir +1 . Envía correos electrónicos a todos en el tema. Usa las reacciones de emoji en el primer comentario.

+1

Hola, ¿tienes alguna noticia sobre esta solicitud de función? Empecé a usar el vscode hoy y ya me encanta, pero realmente extraño los colores que indican los cambios.
Enhorabuena por tu trabajo

+1

Al implementar esto, considere 206

Agrego algunas capturas de pantalla para ayudar:

Atom predeterminado:

VSCode predeterminado:

+1

+1

Sería muy útil.

ya existe la posibilidad de modificar la forma en que se enumeran los archivos y los iconos en el árbol de archivos.
Esta extensión lo hace
https://github.com/robertohuertasm/vscode-icons.

Sin embargo, no colorea los nombres de los archivos.

+1

+1

¿hay cambios? Esta característica me impide moverme de Atom. :(

Me alejé de Atom porque el rendimiento se siente mucho mejor en VSC. Sin embargo, esta es una característica de lujo que extraño en VSC.

+1

Creo que sería bueno tener esto como una configuración incorporada (por ejemplo, git.colorExplorer ) en lugar de una extensión.

@arkon, ¿existe tal extensión? No pude encontrar ninguno.

Lo más probable es que el explorador de archivos no tenga una API para modificarlo de acuerdo con
para realizar cambios. Una extensión estaría bien para mí.

El viernes 3 de febrero de 2017, a las 07:52, Rahul [email protected] escribió:

@arkon https://github.com/arkon ¿existe tal extensión? No pude
encontrar cualquier.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Microsoft/vscode/issues/178#issuecomment-277177373 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AEQJ1eoLm7Sp59a2hE0tIFQnb0Q5cJnSks5rYs6tgaJpZM4GlYyH
.

@ rahulnever2far No, fue solo una sugerencia, ya que se sugirió anteriormente que podría exponerse como una API de extensión (lo cual también está bien, supongo).

Recientemente decidí pasar a VSCode y realmente extraño esta característica

Por favor añadir. Agrega fricción a la productividad al intentar saltar de Atom.

@KozhokarAlex @bhudgens y otros: haga clic en el icono de pulgar hacia arriba en la primera publicación para mostrar a los desarrolladores que solicita esta función. Clasifican los problemas con el visto bueno para determinar qué solicitudes de funciones son las más populares.

Como puede ver en este tipo de clasificación de problemas, este problema es la tercera característica más solicitada en este momento.

Pulgares hacia arriba. Recientemente vine de Atom ... ¡espero verlo pronto en VSCode!

¡Ah, gracias @joaomoreno!

Agregue también el mismo estado de coloración / qit a QuickOpen, no solo FileExplorer.
De esta forma, los archivos de apertura se pueden filtrar visualmente en función de los archivos ya modificados.

que esta pasando con esto? ¿Por qué los mantenedores no fusionan @joaomoreno PR? ¿Hay algún complemento que podamos usar ahora? esto es solo un plan tonto

@SOSANA No está seguro de lo que quiere decir con relaciones públicas, ¿a qué relaciones públicas se refiere?

2824 abre la puerta para arreglar este, así que ten un poco más de paciencia.

@SOSANA eso es un problema, no un PR 🤣

+1 esta característica sería increíble para la productividad

+1

@ publiclass1 @ hevans90 , ... (inserte a todas las demás personas que comentaron con +1) ..., POR FAVOR no publique comentarios sobre cuánto desea esta función. Esto es para lo que GitHub agregó las reacciones emoji. Solo aprueba el comentario original. De esa manera, puedo volver a usar las notificaciones por correo electrónico para lo que estaban destinadas (mantenerse actualizado sobre el progreso de este problema, y ​​no todo el mundo que quiera esto). Lo siento a todos por enviarte spam también. Espero sinceramente que más personas aprendan a detener los problemas de +1 -ing.

+1

Yo uso PhpStorm pero prefiero usar VS Code para todo. Actualmente uso tantas ventanas de VS Code como puedo. ¿Podrías finalmente tener este sistema de coloración como una opción, ya que prefiero / conozco los colores de PhpStorm? Para referencia:

Negro: actualizado: el archivo no ha cambiado.
Gris: eliminado: el archivo está programado para su eliminación del repositorio.
Azul: modificado: el archivo ha cambiado desde la última sincronización.
Verde: agregado: el archivo está programado para agregarse al repositorio.
Marrón - Desconocido - El archivo existe localmente, pero no está en el repositorio y no está programado para agregarse.

etc a través de https://www.jetbrains.com/help/phpstorm/2016.3/file-status-highlights.html . Ustedes son geniales, gracias.

y

• los archivos que se fusionaron con conflictos se muestran en rojo,

es muy conveniente distinguir en conflicto de otros

+1 Tener que alternar entre las vistas de Git <> Explorer es muy improductivo.

Idealmente, también sería posible ver el conjunto de cambios como un grupo en la parte superior donde tenemos archivos abiertos, así como un árbol anidado de cambios visualizados por color (como se muestra en @abdonrd arriba).

Venid, chicos, basta con el +1.

Por favor coloque un pulgar hacia arriba en la primera publicación.

Tengo un caso de uso y un argumento interesantes para hacer una API genérica que permitiría que el complemento coloreara archivos y carpetas individuales:

El envejecimiento de archivos / carpetas es similar al encendido de envejecimiento de Trello : me gustaría que los archivos y carpetas que no se han tocado durante mucho tiempo (juzgados por el historial de git) se desvanezcan, para que el 'conjunto de trabajo' sea más distinto y más fácil de encontrar.

Por qué: tengo un gran repositorio de proyectos pequeños (piense en un montón de scripts para el informe analítico) donde el 90% del trabajo no se volverá a tocar (pero no puedo mover cosas viejas a la subcarpeta porque rompería una gran cantidad de enlaces que apuntan al repositorio).

Si hubiera un punto final de API para colorear elementos del árbol, podría escribir un complemento que lea el registro de git y coloree cada archivo / carpeta de acuerdo con un conjunto de reglas.

Entonces, ¿qué pasa con eso, todavía no hay una API que permita crear una extensión para esto, o esto se implementará como una característica integrada?

¿Algún avance en esto?

+1

+1

+1

¿Pueden dejar de hacer +1 y enviar spam a nuestras bandejas de entrada de correo?

No sirve para nada.

+1 para no enviar spam xD

protip: filtra los mensajes de github donde el cuerpo es igual a / coincide / lolwuts "+1"

no puedes detener a esta gente.

@jmbelloteau como @fredrikaverpil dijo anteriormente en los comentarios, los problemas de VSCode se ordenan por el número de aprobaciones al comentario original. Por lo tanto, comentar "+1" en lugar de agregar una reacción al primer comentario es, de hecho, spam, ya que no es la forma correcta de proporcionar comentarios y solo envía correos electrónicos inútiles a todos. Y al contrario de agregar una reacción, ni siquiera se tomará en cuenta.

+1

También estoy tan acostumbrado a esto en Webstorm: D. Pero como puedo ver, esto probablemente se desarrollará más temprano que tarde. Aquí hay una captura de pantalla de Webstorm para inspirarte (siguiendo a @abdonrd):

¡Ah, también los archivos sin seguimiento se muestran en rojo!

+1

Acabo de probar el código VS por primera vez hoy (procedente de Atom) y una de las primeras extensiones que busqué fue "git status" resaltado en la vista del explorador. La pestaña "control de código fuente" por sí sola es muy agradable, pero tener carpetas / archivos resaltados me permite navegar rápidamente al componente en el que estoy trabajando sin tener que dejar siempre mi árbol de directorios expandido (muy útil para las bases de código FE que tienden a tienen estructuras más profundamente anidadas).

idealmente, sería genial si los colores pudieran modificarse individualmente.

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

+1

He estado buscando por un tiempo una buena aplicación que me recuerde que beba agua.
Entonces, me di cuenta de que estoy suscrito a este hilo.
Que sigan viniendo los +1 chicos, ya no son inútiles 🚰

@mmazzarolo
¿Por qué necesitas un recordatorio para beber agua? ¿No es suficiente beber cuando tienes sed?

De todos modos, deja de hacer +1. Estoy seguro de que los desarrolladores ya están al tanto de esto y publicarán actualizaciones a medida que se presenten.

@pohmelie esa es una alternativa válida, ¡gracias!

+1

¿Qué pasa con estas personas +1?

¡Gran idea, @ davidhu2000! También sería bueno admitir colores hexadecimales como git.ignoredFileColor: '#333333' .

Hay una buena lista de los tipos y colores que utiliza JetBrains aquí: https://www.jetbrains.com/help/idea/2017.1/file-status-highlights.html (puede inspeccionar el nombre del color para obtener el hexadecimal).

+1 para generar conciencia sobre cuánto se desea esta función

La única razón por la que no estoy usando VS Code. Demasiado :(

¿Alguien sabe en qué parte del código base se podría comenzar a implementar esto? Quiero intentarlo.

@admosity Alguien ya envió una solicitud de extracción el año pasado que fue rechazada: https://github.com/Microsoft/vscode/pull/8462 .

2824 se mencionó como un bloqueador en algún lugar anterior, que se ha fusionado hace un tiempo. Miraría los cambios allí para asegurarme de que se implemente como lo quiere el VS-Team.

@AndreasGassmann ¡increíble! Echaré un vistazo.

La última característica clave me impide cambiar al código vs

Cuando se incorpore esta función, cambiaré a vscode

Estoy suscrito a este problema porque me gustaría saber cuándo se ha realizado algún progreso.
Todo el mundo es consciente de lo deseada que es esta función y en este momento es el segundo tema más votado :).

Si realmente desea esta función, simplemente vote a favor del primer comentario y evite agregar comentarios repetidos .

Para las personas que sienten que esta función es necesaria para cambiar a VS Code. Puedo decir que fue la primera característica que me perdí al cambiar de Atom, pero en mi opinión, este es un pequeño precio a pagar por este increíble IDE.
Además, la semana pasada tuve que trabajar un poco en Atom y realmente extrañé la vista de git de VS Code.

@waderyan Este es un factor decisivo que se mueve desde el átomo.

¡Sí, por favor!

+1

+1

+1

Hice un truco muy feo que implementa esta característica modificando workbench.main.js e inyectando el CSS basado en la salida de git status . Si no le importa buscar en los archivos internos de VS Code y hacer que su VS Code ejecute git status cada 5 segundos, eche un vistazo.

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

Actualización 28.6.2017: se corrigió un error por el cual el complemento no se cargaba al reabrir el proyecto.
Actualización 30.6.2017: Se agregó resaltado de los directorios principales de los archivos modificados (como lo hace Atom).
Actualización 1.7.2017: la coincidencia de archivos ahora se realiza utilizando la ruta completa de archivo o directorio. Antes de este cambio, el directorio se resaltaba si tenía el mismo nombre que otro directorio modificado.

Hola,
¿No puedo averiguar si esta función está implementada o aún no?
No encontré ninguna configuración ni extensión y como se abrió hace casi dos años, estoy confundido ...

@sanjibukai El problema aún está abierto, por lo que aún no se ha implementado. Sin embargo, puedes usar el truco que @ karabaja4 creó en el comentario sobre el tuyo.

Soy nuevo aquí, pero ¿realmente se necesitan casi dos años para agregar esta característica obvia?
Sorprendentemente, nunca escuché sobre vscode hasta hace poco, pero cuando me enteré, la característica principal que se defendió es precisamente cómo vscode es bueno para integrar git. Y de hecho es bueno.
Qué lástima que todavía le falte esta característica.
Sin embargo, mantén el buen trabajo del equipo vscode 👍

No puedo mantener la concentración sin esta función. Cada vez que tengo que recordar qué archivo edito.

+1

@ karabaja4, ¿por qué no haces un PR con tu truco y obtienes comentarios sobre cómo implementarlo correctamente?

@saada Haría eso si pensara que algo de ese código podría integrarse en VS Code. Ejecutar un proceso de fondo git status seguramente no es una forma sensata de implementar esta función. Cualquier código adecuado que implemente esto debe escribirse desde cero e implementarse correctamente dentro del marco fuente de VS Code. Eso es mucho trabajo y, lamentablemente, en este momento no tengo suficiente tiempo disponible. Perdón :(

La acumulación no ayudará a las cosas cuando ya se dice que la métrica establecida son los números de +1 que obtiene la publicación original, no en las respuestas. Además, considerando que se trata de una herramienta para desarrolladores, me sorprende un poco la cantidad de derechos y la falta de comprensión del proceso de código abierto que está sucediendo aquí. La solicitud de función está aquí como un problema abierto. Puede hacer +1 en la publicación y hacerlo usted mismo (presumiblemente trabajando con los mantenedores para asegurarse de que no sea en vano) y solicitar una fusión o simplemente dejarlo así. Si es una característica vital para usted, utilice Atom. Mientras escribo esto, hay más de 4000 problemas abiertos. Tendrás que tener paciencia.

(o usa el truco @ karabaja4 mientras tanto, ¡gracias por tu trabajo!)

+1
Haciendo esto porque solo escuche hablar devchat y los problemas con más comentarios recibirán más atención

@ karabaja4 gran trabajo. Otro enfoque: ¿qué tal ejecutar git status en init, y luego actualizar cada vez que se activa el evento onFileSave ? ¿Sería esto más eficiente?

quizás podríamos configurar la forma en que actualizamos el estado de git.

+1 esto sería muy útil si se agrega

@Kaijun No estoy seguro de cómo lo implementaría. ¿De dónde vendría el evento onFileSave ?

Si proviene de Code on document save (suponiendo que sepa cómo adjuntarlo), los archivos modificados fuera de Code se ignorarían, al igual que cambios como mover y copiar archivos.

Si proviene de una lógica de supervisión de carpetas que se implementa en el árbol de la solución, esto debería hacerse de forma recursiva para todo el árbol. No estoy seguro de que valga la pena en términos de rendimiento.

@ karabaja4 Creo que Code también detecta cambios externos. Así que conectarse a tal "evento" con tal vez un sistema antirrebote para que múltiples cambios de archivo en el mismo intervalo no activen demasiadas comprobaciones de estado de git. ¡Esto podría funcionar !. ¿Quizás alguien familiarizado con la pieza de fs pueda intervenir?

Esto realmente no debería estar atrasado. Hay un valor muy real en agregar esta característica aparentemente pequeña. La felicidad de los desarrolladores va por el camino. Es desalentador ver que este problema tiene miles de +1 y no se tiene en cuenta desde 2015.

@kamok es cierto! Aunque Atom es lento, tenía otra opción ... Volví a WebStorm, que está invicto por la forma en que se integra con Git y otras funciones para las que tienes que instalar extensiones en vscode, y aún se las arregla para ser tan rápido y parece un editor ligero en lugar de un IDE, en términos de velocidad. Esta característica por sí sola (estado de Git en el explorador de archivos) aún no sería suficiente para mantener a los usuarios de vscode. Esto sería solo una gota en el balde. Es la característica que menos echo de menos, viniendo de WebStorm.
Sugiero que el equipo de vscode eche un vistazo a cómo lo están haciendo los chicos de JetBrains.
Lo siento, pero lo intenté ... He luchado con vscode durante meses, esperé actualización tras actualización, pero todavía me encontré constantemente cerrando vscode y reabriendo el proyecto en WebStorm para: estado de Git en el explorador árbol, Stashes, vista de carpeta / árbol para cambios locales, comparación de ramas, clic derecho> comparar con el portapapeles ... Y estos están justo en la parte superior de mi cabeza. La integración de Vscode Git todavía tiene un largo camino por recorrer si realmente quieren ayudar a los desarrolladores.

_Enviado desde mi Samsung SM-G950F usando FastHub _

@MrCroft Le sugiero que se comunique directamente con el equipo si está tan preocupado por su metodología de trabajo; de lo contrario, haga +1 en el problema con un pulgar hacia arriba y cambie de editor si le molesta tanto.

@cucumbur ya lo hice (cambié de vscode). Solo estoy expresando mi pesar, porque realmente me gustó cómo se sentía vscode. Me hubiera encantado que tuviera una buena integración de Git para poder seguir usándolo. Estoy seguro de que mucha gente siente lo mismo.
Todavía lo vigilaré. Quizás, quién sabe, en un "futuro no muy lejano" se haría ... Aparte de vscode, en realidad soy un gran fan de Microsoft ... Software y hardware, construyen material de muy alta calidad 9 de cada 10 veces . Solo espero que vscode se convierta en uno de los 9.

_Enviado desde mi Samsung SM-G950F usando FastHub _

@kamok Cada nuevo problema entra en espera y permanece allí hasta que se aborde. No creo que esta característica se ignore en absoluto. simplemente requiere más cambios de los que cree. Hasta donde yo sé, quieren que esto sea parte de la API de extensiones, y actualmente el árbol de archivos carece de muchas características para que esto suceda.

Si clasifica los problemas con el pulgar hacia arriba, verá que este problema es el segundo más popular, el primero se está trabajando y casi está terminado. Estoy bastante seguro de que comenzarán a trabajar en esto tan pronto como se complete el otro.

Sin embargo, una actualización ocasional de este hilo sería genial.

El cambio de atom pero en un proyecto grande que no tiene archivos actualizados resaltados hace que sea difícil trabajar con ellos.
Volver a Atom hasta que esta función esté disponible

Quizás valga la pena mencionar que una solución alternativa / provisional que me funcionaría ... es duplicar la estructura del árbol en la vista "Editores abiertos". Por lo general, la vista me muestra archivos "actualizados", pero es solo un volcado de nombres de archivo, por lo que es más difícil trabajar con ellos, a diferencia de si estuviera claro en qué parte del proyecto se encuentran estos archivos.

¿Alguna actualización sobre esto?

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

Soy masoquista, mi propio comentario.

Sigo probando VSCode, pero como falta esta función, me impide cambiar. No me di cuenta de cuánto confío en esta función en Atom hasta que intenté cambiar.

Solo esperando que esto cambie al código VS desde atom, espero que se implemente pronto.

+1

pasaron dos años 。。。

y sorprendentemente tu comentario no terminó por cambiar eso. Aquellos de nosotros que nos preocupamos por el desarrollo y las contribuciones potenciales nos suscribimos a estos temas, su comentario no ayudó en nada y envió un correo electrónico inútil a 99 personas.

Oye, no obtienes ningún resultado a menos que lo intentes, ¿verdad?

Lo eché mucho al principio, y aunque sería muy conveniente tenerlo, el 'diff explorer' (tercer ícono en el menú vertical) es realmente poderoso y muy útil

+1
¡Sería genial si esto implementara wooow ...!

Escribí una tarea de trago que debería simplificar la instalación del truco (solo 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

PD Aún no probado en todas las plataformas, agradecería que alguien lo probara en OSX.

@ karabaja4 No parece que su 'truco' sea tan complicado de implementar en vscode. Como parece que los desarrolladores de vscode no están solucionando este problema en el corto plazo, ¿tal vez podría crear una solicitud de extracción?

@ karabaja4 ¡ Gracias por esto! Trabajando para mí en macOS Sierra, VSCode 1.15.1.

@ karabaja4 ¡Gracias! Trabajando aquí en Fedora 26, VSCode 1.15.0. Ese solo hizo que el cambio de Atom fuera mucho más conveniente.

@ karabaja4 +1 ¡¡Gracias !! Trabajando para mí en Ubuntu 14.04 64, VSCode 1.15.1 (instalación manual)

+1

@ karabaja4 +1 Esto es increíble.

+1

@matti más uno

_Enviado desde mi HTC MSM8996 para arm64 usando FastHub _

@ibrokemypie menos dos

Enviado desde mi HTC MKB826262 para arm32 usando Lolbug

¿Alguna novedad sobre esta función?

+1

+1

+1

@ karabaja4 GRACIAS hombre = D <3

+1

Vaya, esto debería haberse implementado hace dos años.

@eosrei +1

+1

+1
Afrontemos la realidad; Me encanta VSCode, pero la pestaña de Git realmente apesta

@ karabaja4 Hola, acabo de salir la portarás tu truco en esta versión? Gracias.

EDITAR: Funciona con 1.16, pero no cuando se usan espacios de trabajo de múltiples raíces.

@ karabaja4 👍

@ karabaja4 acaba de

+1

+1

Un comentario de +1 debería ser una prohibición automática de los problemas de GitHub ...

Sería mejor si GitHub solo analizara las publicaciones +1 y las reemplazara automáticamente con una reacción de emoji de aprobación a la publicación original.

@ karabaja4 su truco se ejecuta en OSX 10.12.6 - ¡increíble! Gracias.

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

Lo único es que ahora recibo un mensaje de advertencia al arrancar. Afortunadamente, es solo una advertencia.

VSCode versión 1.16.0

+1

¿Hay alguna razón por la que esto aún no se haya implementado o hay algún cronograma en el que se agregará esta función?

Ayer, volví a Atom durante una hora para usar su última actualización de ide y pensé que mi vida es tan fácil con archivos de colores en la vista de árbol de archivos.

Editar: Acabo de encontrar una solución. ¡Agregar una línea a uno de los archivos de código vs (<1 minuto de esfuerzo) funciona a las mil maravillas! https://github.com/karabaja4/vscode-explorer-git-status

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

¿Alguna vez has visto que podrías usar la reacción de emoji en lugar de publicar +1 ?

Cada vez que publicamos comentarios en github, todos los suscriptores del tema reciben notificaciones y algunos usuarios también reciben correos electrónicos. Es un poco frustrante leer un correo electrónico escrito: +1 y puedes ver en esos comentarios, hay muchos: -1 :.

La comunidad aprecia si todos comenzamos a usar las reacciones en su lugar:
https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments

Pido disculpas por cualquier ofensa con esta información y por los demás que reciben esta notificación.

Había leído en otros hilos que Microsoft calificó la prioridad de una función por el número de comentarios +1. Pido disculpas si me equivoqué y no es de ninguna manera cómo se clasifica una función. Eliminé mi comentario. De cualquier manera, ¿qué pasa con la actitud agresiva, hermano? Podrías haber señalado lo mismo con mejor tono @leocaseiro

Salud.

Hola @aecorredor , me disculpo si sonó grosero.
No soy un hablante nativo de inglés y quizás una de mis expresiones traducidas sonaba mal. Por favor, ayúdame a mejorar la descripción de ese comentario. ¿Debo reemplazar la palabra molesto? ¿inútil? Gracias.

PD: Me alegra que hayas editado el mundo que he leído en mi correo electrónico, porque puede que haya sonado grosero, pero nunca fue mi intención ofender a nadie.

Actualización: reemplacé mi comentario anterior, por favor avíseme si suena mejor. Gracias

Hola @leocaseiro ,

Perdón por escribir esa mala palabra en primer lugar. De hecho me di cuenta
que probablemente la barrera del idioma era lo que estaba causando la confusión. Pero
sí, reemplazaría esas dos palabras con algo más parecido a:
"Por favor, todos estamos tratando de mejorar la experiencia general de github para
problemas abiertos / solicitudes de funciones, y sería bueno que la gente comenzara a usar
reacciones emoji en lugar de comentarios como "+1", que simplemente crean
sobrecarga innecesaria en el hilo y desencadenar correos electrónicos que no son realmente
contribuyendo de manera significativa. Consulte este enlace para ver cómo
Las reacciones emoji funcionan: {Enlace aquí}

Saludos y sin resentimientos.

Mejores.

El lunes 18 de septiembre de 2017 a las 11:44 p.m., Leo Caseiro [email protected]
escribió:

Hola @aecorredor https://github.com/aecorredor , pido disculpas si suena
maleducado.
No soy un hablante nativo de inglés y quizás uno de mis traducidos
las expresiones sonaban mal. Ayúdame a mejorar la descripción de
ese comentario. ¿Debo reemplazar la palabra molesto? ¿inútil? Gracias.

PD: Me alegro de que haya editado el mundo que he leído en mi correo electrónico, porque puedo
Han sonado groseros, pero nunca fue mi intención ofender a nadie.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Microsoft/vscode/issues/178#issuecomment-330420547 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AIsVa9fgWXPMFBgkZdHjQHKhUEDJb8Bmks5sjziWgaJpZM4GlYyH
.

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

Utilice una reacción en lugar de un comentario "+1".

+1

Realmente esperaba que el número de +1 disminuyera después de los comentarios anteriores, pero de repente apareció otro +1 😁.

Es una pena, porque los programadores a menudo culpan a los usuarios por no leer los mensajes de error, pero no pueden leer algunos comentarios o instrucciones.

¿Quizás valdría la pena poner algo en README.md para pedir a los usuarios que usen reacciones en lugar de comentar +1? Quizás en CONTRIBUTING.md esté un poco oculto.

No lo sé, creo que me daré de baja y esperaré las notas de la versión cuando esté lista.

He creado un Gist que se encarga de esto. La solución de @ karabaja4 no @dseipp que nunca se fusionó. Todavía había algo mal con su PR (¿creo que faltaba el soporte en escena?), Así que lo arreglé.

Entonces, si desea que esto funcione mucho mejor, consulte mi esencia: https://gist.github.com/WadeShuler/1637073371ad126779076344c34278f3

@ikatyang : lo siento, ¿eso significa que esta función se introducirá en octubre (2017) ...?

@nkkollaw el enlace era de este comentario: https://github.com/Microsoft/vscode/issues/34160#issuecomment -331066864

El comentario solo pedía discutir cosas relacionadas con este tema aquí, y no en el "Plan de iteración" (y pedir discutirlas en inglés).

Ah, lo tengo @tiangolo , gracias.

Intentaré aguantar Atom hasta que haya una API para implementar esta funcionalidad (lo siento, no soy lo suficientemente bueno para ayudar en absoluto con esto).

Estoy trabajando para hacer la actualización dentro del propio proyecto.
Por ahora, hice una prueba de concepto que está funcionando pero no paso el tslint, porque todavía necesito entender las capas para poner todo en el lugar correcto.
Pondré algunas actualizaciones aquí, y si alguien quiere ayudarme, pondré el enlace a mi solicitud de extracción más tarde, así que puedes ayudarme.

¡Planeado en la iteración de octubre de 2017! 👍

Tenemos una primera versión de esto. Todos tengan la seguridad de que esto llegará en octubre.

Un poco más de información:

• Los colores se definirán en temas, lo que significa que se pueden adaptar a su gusto.
• Habrá una configuración para habilitar / deshabilitar este
• Esto no es exclusivo del control de versiones. También estamos buscando resaltar errores / advertencias en el explorador de archivos (ver # 782) y estamos pensando en exponer esto a los autores de extensiones.

Preguntas abiertas:

• ¿Es suficiente usar solo un color? ¿Debería haber también una sugerencia textual y / o de íconos?
• ¿Qué estado de hijo debería recoger un padre? ¿Debería esto ir por importancia? Eso es fácil con errores y advertencias, pero ¿qué es más importante, un archivo modificado, sin seguimiento o ignorado?
• ¿Deberíamos mostrar estas decoraciones de archivos también en el contenedor "Editores abiertos" y / o en el selector de archivos, etc.?

Mantendré este problema actualizado mientras suceden cosas. Como siempre, utilice las emociones en lugar de los comentarios "+1". ¡Gracias y Feliz Codificación!

Personalmente, lo que veo en la imagen de arriba es suficiente. ¡Luce genial y gracias!

¿Parece que se pierden los archivos ignorados por .gitignore en gris oscuro?

No cambia el color (atenuado) de una carpeta principal solo por un archivo ignorado en su interior. Solo lo atenúa SI se ignora la carpeta en sí. Por favor, vea mi comentario / corrija algunos comentarios. Hace que Git descargue los estados y detecte si es un directorio o un archivo. Simplemente agregar clases a los archivos / carpetas en el árbol de archivos funcionaría ... Como "git-status-modified" o "git-status-added". Entonces los temas pueden hacer su magia.

Sería bueno si ustedes pudieran dejarnos ver en qué están trabajando, para que podamos jugar con eso y crear relaciones públicas. Honestamente, si está estropeado, la gente probablemente dejará de usar Code si no se puede lograr una solución viable en un tiempo razonable. Muchas personas (incluyéndome a mí) han dejado Atom por problemas similares.

También creo que si hay errores, tal vez use un punto antes o después del nombre del archivo en el árbol. Esto no sería molesto, dejaría que los temas los diseñaran y no interferiría con el resaltado de color de Git.

¡Sí, esto DEBE abrirse a los desarrolladores de extensiones! Ya debería haberse hecho. ¿Por qué no querríamos tener control sobre el árbol de archivos para crear extensiones geniales o arreglar cosas que ustedes no?

¿Parece que se pierden los archivos ignorados por .gitignore en gris oscuro?

Claro, es un trabajo en progreso y las cosas suceden una a la vez. Los archivos ignorados vendrán, también en octubre.

Sería bueno si ustedes pudieran dejarnos ver en qué están trabajando, para que podamos jugar con eso y crear relaciones públicas.

Claro, todo está en la rama joh/feco . Hay un nuevo servicio de decoración que utiliza proveedores para los datos reales. En el lado del consumidor está la etiqueta de archivo que usamos para representar los nombres de los archivos.

No cambia el color (atenuado) de una carpeta principal solo por un archivo ignorado en su interior. Solo lo atenúa SI se ignora la carpeta en sí. Por favor, vea mi comentario / corrija algunos comentarios.

Creo que "los archivos ignorados y sus hijos (si los hay) están en gris" es bastante claro.

@nkkollaw ¡ ¿

En @jrieken dijo:

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

Indicó un archivo ignorado que posiblemente influye en el estado de las carpetas principales, ¡lo que no debería!

Tu mensaje pasivo agresivo solo está obstruyendo este hilo con mensajes inútiles ...

@WadeShuler : No tengo idea de qué _tú_ estás hablando.

Acabo de señalar que los archivos ignorados y sus hijos deberían aparecer atenuados, y está bastante claro que esta definición no pide que los padres de los archivos ignorados estén atenuados.

Como para:

Tu mensaje pasivo agresivo solo está obstruyendo este hilo con mensajes inútiles ...

No tengo idea de cómo mi mensaje fue pasivo-agresivo, supongo que no sabes lo que significa, pero tú eres el que está obstruyendo este hilo, ya que eres el único que ha comentado después de mi mensaje.

Extraño.

guau ... buena idea! ¡me gusta esto!

Me gustaría tener el xcode como una pista textual de un solo carácter en una columna de la derecha. Hace que los archivos sean fáciles de filtrar / seguir visualmente.

@nkkollaw dije:

No cambia el color (atenuado) de una carpeta principal solo por un archivo ignorado en su interior. Solo lo atenúa SI se ignora la carpeta en sí.

Claramente, estoy hablando de carpetas de padres, no de hijos. Aquí te hice un dibujo:

Aquí está el .gitignore en el directorio principal, web como referencia:

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

Mi mensaje fue una respuesta a la respuesta de @jrieken del WIP, aquí , donde dice:

¿Qué estado de hijo debería recoger un padre? ¿Debería esto ir por importancia? Eso es fácil con errores y advertencias, pero ¿qué es más importante, un archivo modificado, sin seguimiento o ignorado?

Indica que un padre de un archivo / carpeta "ignorado" puede tener un estado, que no es así. De ahí mi respuesta. Estás confundiendo lo que ves visualmente frente a lo que Git realmente usa para su 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 en .gitignore con una regla especial, por lo que no es solo backend/web/assets/ y específicamente son los directorios de activos con nombre aleatorio. No especifica todos y cada uno de los archivos ignorados, cuando se trata de un directorio donde se ignoran sus contenidos. Como los directorios vendor o node_modules . Solo tienen una entrada en la entrada git status ignorada.

En el árbol de archivos, debe agregar una clase de git-status-ignored a TODOS los elementos (archivos y carpetas) que comienzan con backend/web/assets/6f57f06b/ .

El CSS para que coincida con la carpeta del árbol de archivos backend/web/assets/6f57f06b/ es así (¡actualmente toma 2 reglas!):

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

Y

#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: En la primera regla, hacemos coincidir el título con un signo = solamente, ¡así que exactamente! En la segunda regla, hacemos coincidir todos los títulos con ^= , por lo que el comienzo de la cadena, coincide con todo lo más profundo que eso también (todos los niños).

Para hacer coincidir un directorio se necesitan 2 reglas CSS. Así que creo que mientras hacemos esto, deberíamos seguir adelante y hacer el title en el elemento HTML para directorios, para incluir una barra al final. Puedes ver de lo que estoy hablando en esta captura de pantalla:

Sí, tu comentario fue pasivo-agresivo, ya que estabas siendo grosero / sarcástico / cutre sin decir las palabras. Además, estabas equivocado. Nadie dijo nada sobre los niños y ni siquiera es de lo que estábamos hablando.

@jrieken
La forma en que funciona mi configuración de Atom: "editado" tiene prioridad sobre "agregado". Eliminar un archivo no muestra ningún estado. No hay estado para "en etapas". Creo que otros deberían verificar su configuración de Atom y ver si esto también es cierto para ellos, y que no es solo mi configuración. Sería bueno agregar código para cada situación y dejar que el usuario lo edite para que funcione como lo desee.

Tal vez agregue varias clases, de modo que los directorios principales en todo el árbol tengan "git-status-added" y "git status-modified". Tal vez incluso agregue "git-status-deleted" si se ha eliminado algo debajo de él.

Luego, use css para hacer coincidirlos. Si desea un color diferente para .git-status-added.git-status-modified , puede hacer una fuente naranja con un subrayado verde (naranja para modificado, verde para agregado). Si solo tuviera la clase .git-status-added , haga que la fuente sea verde.

Realmente no importaría una vez que les agregue clases, todos pueden crear algo de CSS como quieran. Sin embargo, querría un stying predeterminado "bastante bueno" fuera de la caja.

Tiraré de esa rama cuando tenga tiempo y lo comprobaré.

¿Cómo manejar los errores de pelusa y el estado de git?

Atom pone una línea ondulada roja debajo del nombre del archivo, como puede ver aquí:

Creo que deberíamos agregar una clase como lint-error al mismo elemento que el estado de git, que nosotros (y los temas) podemos anular a través de nuestras propias hojas de estilo.

Entonces, el div para el mismo elemento en el árbol de archivos que usé como ejemplo anterior (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>

Se vería así, cuando aplicamos un estado de git de git-status-edited y 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>

Entonces podríamos hacer coincidir a través de 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;
}

¿Tienen un Slack? Hay muchos archivos editados en la confirmación. Estoy buscando exactamente dónde está aplicando el color de estado de git al árbol de archivos. ¿Está en /extensions/git/src/repository.ts ?

Gracias a todos y gracias por aclarar las reglas de cambios, archivos sin seguimiento e ignorados. Los iniciados del mañana se enviarán con una versión anterior de esto.

Un par de cosas

• Por defecto hay una combinación de color y bagde.
  
  
  
  • habilitar / deshabilitar iconos con: "explorer.decorations.badges": true|false
  
  
  • habilitar / deshabilitar colores con "explorer.decorations.colors": true|false
  
  
• Los colores se muestran en el árbol de archivos, la sección de editores abiertos y en el viewlet de SCM
• Hay tres colores para empezar. Puede personalizarlos en la configuración workbench.colorCustomizations . Los colores son gitDecoration.modifiedResourceForeground ,
  gitDecoration.deletedResourceForeground ,
  gitDecoration.untrackedResourceForeground ,
  gitDecoration.ignoredResourceForeground , y
  gitDecoration.conflictingResourceForeground
• Tenga en cuenta que los nombres de las configuraciones, etc. probablemente cambiarán, es posible que se agreguen nuevas configuraciones y que otras configuraciones se eliminen nuevamente.

FYI: editado para reflejar los cambios realizados después de la publicación inicial

Creo que es mejor no aplicar los iconos del lado derecho a los directorios principales. Puede haber una opción al menos.

Esto parece haber sido actualizado en la versión privilegiada con scm.fileDecorations.useIcons y scm.fileDecorations.useColors reemplazados por scm.fileDecorations.enabled que da tanto los iconos como los colores.

Me gustaría tener solo los colores pero no los íconos. Es decir, el comportamiento "antiguo" de scm.fileDecorations.useIcons : false y scm.fileDecorations.useColors : true

He intentado experimentar con explorer.decorations.badges y explorer.decorations.colors pero parecen no tener ningún efecto.

EDITAR:
Estoy ejecutando la versión 1.18 insider, Commit f1ee80be081b0d ... en Windows 10
(Sería bueno si el texto en el cuadro de diálogo Acerca de pudiera resaltarse para que pueda copiar)

¡Gracias por armar esto @jrieken !

Tuve un par de pensamientos:

• parece que el color seleccionado sigue siendo el gris antiguo en lugar del color de estado
• estuvo de acuerdo con la opción de tener íconos o no (por @FredrikFolkesson )
• con los iconos que muestran, si el color modificado / actualizado es claro, la 'M' o la 'U' deben estar oscuras (o viceversa) para que el contraste esté ahí y sea más fácil de leer.

¡Espero no tener que actualizar el archivo main.js con cada compilación para obtener los colores!

Problema menor (utilizo los últimos iniciados a partir del 16 de octubre) para informar,

Otro problema que me gustaría abordar es el mismo código de color no solo para el árbol del proyecto, sino también para la sección de editores abiertos. Actualmente, no hay forma de ver en la sección de editores abiertos cuáles de los archivos se modificaron y cuáles no. La capacidad de averiguar rápidamente qué editores son para archivos modificados es MUY conveniente, de modo que uno puede saltar entre los archivos que modifica rápidamente y no hay necesidad de intentar recordar los nombres de los archivos actualmente modificados.

Esto sería una gran característica. Nuevo en VSC de Atom y lo extraño mucho.

También se mudó de Atom y también falta esta característica. ¿Cuándo está programado el lanzamiento de esta función?

Del mismo modo, es más importante porque los archivos gitignored son demasiado prominentes en la lista y se confunden con todo ...

Hola, creo que también necesitamos una clave de color para cambiar el color de primer plano de las insignias (# 36246)

Gracias a todos por los continuos comentarios. He actualizado mi comentario de resumen inicial para reflejar los cambios recientes. También me aseguré de que los cambios en la configuración se reflejen sin recargar y de que el color de estado prevalezca sobre el color de selección.

De forma predeterminada, todavía usamos color y una insignia, principalmente por dos razones: no todos saben de inmediato lo que significa el color y tener la insignia (con su información sobre herramientas) puede hacer que esto se explique por sí solo. En segundo lugar, hay personas, como yo, que tienen dificultades para diferenciar esos colores y la insignia está destinada a hacer esto un poco más accesible.

@jrieken ¿Puede decirme si las clases de CSS se están aplicando a los elementos del explorador del árbol de archivos de la izquierda? Esto proporcionaría la mejor capacidad de expansión y facilitaría a los desarrolladores de temas, y a nosotros personalmente, personalizar y anular los colores.

Por ejemplo: cuando las correcciones de su nuevo código marcan un archivo o carpeta como agregado, debería agregar una clase como git-status-added . Luego, podemos apuntar a si a través de nuestras hojas de estilo para personalizar los colores y no quedarnos atascados con lo que nos brindas de inmediato.

@WadeShuler Nuestras personalizaciones de tema / color no funcionan directamente con CSS, sino con algo que llamamos colores de tema . Es una indirecta, dando nombres a ciertas cosas como editorLineNumber.foreground es el nombre del color de primer plano para los números de línea. Los temas asignan colores a esos nombres y el editor recoge esos valores al renderizar. Consulte esto para obtener más antecedentes al respecto: https://code.visualstudio.com/docs/getstarted/theme-color-reference

Con los próximos iniciados, probablemente mañana 19, habrá una representación especial para los archivos ignorados ( git.color.ignored ) y los colores / insignias se mostrarán en la sección "Editores abiertos". He actualizado https://github.com/Microsoft/vscode/issues/178#issuecomment -335511695 en consecuencia.

@jrieken ¡Impresionante! ¿Qué tal una clave de color para el primer plano de las insignias de git?
https://github.com/Microsoft/vscode/issues/178#issuecomment -336904514

¡Muy buen trabajo! Es genial ver que esta característica viene a vscode.

En la implementación actual, los archivos modificados en un submódulo aún no están marcados correctamente como modificados.

En el siguiente ejemplo:

El repositorio principal incluye un submódulo en src/components/ . Se han modificado varios archivos en el submódulo. vscode informa correctamente que src/components/ se modificó, pero no indica qué cambios se realizaron en el submódulo.

Atom identifica correctamente los archivos modificados:

Este problema probablemente esté relacionado con https://github.com/Microsoft/vscode/issues/7829

@jrieken ¡Impresionante! ¿Qué tal una clave de color para el primer plano de las insignias de git?

@equinusocio No te preocupes, sucederá pero hay que pensarlo un poco. Está programado para octubre

@jrieken ¡ Gracias !. Me perdí algo ... ¿los iconos de carpeta también obtienen el color modificado / agregado? ¿Hay una nueva clave para agregar al tema de íconos para establecer íconos diferentes para las carpetas cuando se editan / modifican git?

@jrieken : problemas en 1.18. Quiero agradecerle su trabajo hasta ahora. Acabo de probar los Insiders v1.18. Eché un vistazo al hilo de arriba, así que disculpe si ya tiene algo en proceso para 1.19 para abordar lo que menciono a continuación.

1) El estado "agregado" en el árbol de archivos parece "actualizado y no combinado" con la insignia "U". Los archivos agregados deben tener una insignia "A".

2) No hay una opción de color para git.color.added

3) No hay una opción de color para git.color.ignored .

4) (Fallo) Trata los archivos "agregados" como "sin seguimiento". Inspeccioné un archivo "agregado", y parece que en el html cree que no está rastreado. (el título span dice "sin seguimiento" y la clase es monaco-decorations-style-32 , el icono "U"). Esto es evidente cuando se cambia el color en workbench.colorCustomizations por git.color.untracked , ya que controla los supuestos archivos "agregados".

5) Admite el estado "R", para "renombrado" o movido, agrega una insignia "R" y agrega la configuración git.color.renamed .

Gracias, espero probar 1.19 👍

@danjjl Hay un PR pendiente para # 7829 Con eso aplicado, los submódulos de git obtienen la coloración.

Hay un problema potencial, ya que si se cambia el submódulo, no sé si (el directorio que es la raíz del submódulo) se tratará como el color del estado del directorio en el repositorio principal de git, o un diferente color basado en los archivos contenidos.

Es decir, no sé si el color del directorio del submódulo se basará en el 'estado de git' en el directorio principal o en el submódulo. De todos modos, puede que no importe.

@jrieken ¿Tiene un grupo de Slack o en algún otro lugar para discutir este tema? Puedo ayudar :) Pude extraer, desarrollar y depurar los cambios actuales de la rama maestra. Arreglé los archivos "agregados" que se mostraban como "U", e incluso agregué soporte "por etapas". Dado que fue mi primera vez en el proyecto, lo estoy restableciendo a maestro y haciéndolo de nuevo. Hice un montón de cambios y quiero entrar como un cirujano y no como un arma nuclear.

¿Por qué hay controles en raw.x + raw.y seguidos de controles en raw.x luego raw.y ? Parece hacer que coincida con 2 estados diferentes.

¿Por qué hay 2 constantes de estado para ADDED / INDEX_ADDED , MODIFIED / INDEX_MODIFIED y algunas otras? Entiendo todos los diferentes estados de Git, pero tendría sentido manejarlo para el usuario final, no el nombre de los estados de Git. ADDED debe usarse para lo que tiene ahora como UNTRACKED para luego tener un código de configuración de git.color.added . Creo que algunas de estas constantes de estado están duplicadas y deberían simplificarse y limpiarse.

Un estado de git de _M <- subrayado = espacio / nada, coincidiría con raw.y y ustedes lo tienen como INDEX_MODIFIED . Esto es incorrecto, el estado donde x = nada e y = M representa staged .

Por alguna razón, a veces al azar, parece no reflejar los cambios. Además, parece que los cambios de estado de git se escanean de forma recursiva de arriba a abajo. Si tiene un proyecto grande, puede ver cómo el estado "ignorado" fluye hacia abajo a través de sus carpetas / archivos. Para acelerarlo, navegando más profundo, pareció activarlo para ese directorio y atenuarlo. - ¿Este proceso ralentiza mucho el sistema / VSCode? ¿Alguien lo ha evaluado? Realmente no es necesario revisar cada archivo / carpeta cuando se ignora el padre. Los niños deben obtener sus estados de sus padres. - Si tiene 5,000 archivos ignored pero todos en 2 directorios (es decir: node_modules, proveedor) entonces no deberíamos procesar 5,000 archivos, solo 2 directorios que controlan la apariencia de sus hijos.

Rehaceré mis cambios más tarde hoy y emitiré un PR.

Gracias de nuevo por tu trabajo. Solo estoy tratando de ayudar en lugar de insistirte, ya que en realidad puedo hacerlo jajaja 👍

@WadeShuler Puedo responder algo de eso. Supongo que está buscando en Repository.updateModelState () en repository.ts. Si observa los controles raw.x + raw.y, todos regresan, por lo que en realidad no puede hacer los controles raw.x y raw.y. La razón por la que raw.x y raw.y están separados, y la razón para el INDEX_ * es que cada INDEX_ * está organizado, es solo lo que está organizado lo que cambia. Si reemplaza INDEX con STAGE, creo que tiene más sentido, aunque la lógica que están usando es técnicamente correcta. Consulte https://git-scm.com/docs/git-status , particularmente la tabla "Significado XY"
(EDITAR: vaya, ese formato era incorrecto. Simplemente vaya al original. Es una tabla en rojo a la mitad).
Eso es claramente lo que están usando para todo esto.

Y creo que está equivocado en el caso _M, que coincidiría con MODIFICADO, Índice sin modificar (es decir, sin etapas). A menos que, por supuesto, esté viendo un duplicado de este código en otro lugar.

@petkahl Gracias, estoy familiarizado con el formato corto de estado de Git . Lo usé hace semanas para corregir el estado de mi

Es posible (de alguna manera) obtener _M (subrayado = espacio). No estoy seguro de cómo, por qué, cuándo ... obtuve esto hoy más temprano (así como hace unas semanas cuando trabajaba en mi Gist):

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

Ahora, unas horas más tarde, lo ejecuto y obtengo "A". No sé qué ha cambiado desde entonces ...

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

Cuando estaba investigando para mi Gist, creo que llegué a la conclusión de que es posible obtener "A_" y "_M" para la puesta en escena. También encontré un sitio que había desglosado el estado mucho más claro que los documentos de git-status, simplemente no puedo encontrarlo de nuevo lol.

También puede obtener "AM" para un archivo modificado y preparado. Cree un nuevo archivo vacío, agréguelo (organícelo), edite el archivo y guárdelo, verifique el estado:

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

Entonces, ¿debería tener 2 insignias, "[S] [M]"? Prefiero saber qué archivos he preparado. Es útil para la recolección de cerezas. Puede resultar útil seguir viendo si ha modificado un archivo provisional. Debería tener al menos una insignia organizada.

@WadeShuler Puedo obtener _M consistentemente, al confirmar y modificar. Lo que significa que no ha cambiado (_ = espacio) en el índice, pero modificado en el árbol de trabajo.
asi que:
Crea un archivo: ??
git agregar archivo A_
git commit (no en estado, pero el equivalente al espacio espacio)
modificar el archivo: _M
git agregar archivo M_
modificarlo de nuevo: MM

Realmente no tengo una opinión sobre las insignias cuando tiene dos. Nunca me registro sin mirar la ventana de estado, que la desglosa claramente, al igual que lo hace el estado de git normal. ¿Quizás solo una configuración que te permite elegir cuál tiene prioridad? Pude ver argumentos para ambos. O dos insignias, supongo. ¿Sería igual para la coloración?

He agregado Staged soporte. Puede ver los cambios aquí: WadeShuler / vscode: gitstatus-fix . También hice que algunas de las insignias en la pestaña Estado de Git se vieran un poco mejor al hacerlas un poco más grandes.

Por alguna razón, eliminó el oscurecimiento / ignorar el directorio vendor , pero su contenido en el interior todavía está atenuado y se ignora. No entiendo por qué mi simple modificación dejó de poner gris en el directorio vendor . Ese es el único problema con lo que acabo de hacer, y por qué no emití un PR todavía ...

Si se van a incluir colores / iconos de archivos por etapas, definitivamente debería ser opcional. Personalmente, preferiría no ver la puesta en escena en mi lista como un color diferente al color original nuevo / modificado.

Una vez que comienzas a incluir etapas, puede complicarse rápidamente ya que existe la posibilidad de incluir todas las combinaciones y permutación de nuevo / nuevo-escalonado / modificado / modificado-escalonado / modificado-escalonado-modificado / nuevo-escalonado-modificado, etc. , lo que dará lugar a una enorme matriz de colores y confusión.

Voto por no complicar demasiado el asunto.

Estoy de acuerdo @dseipp. Esa es la razón exacta por la que no fusioné el soporte para archivos en etapas en mi truco inicial cuando lo hice, ya que no vi ningún uso para que los archivos en etapas fueran coloreados.

El propósito del resaltado de color es que me permite encontrar archivos nuevos / modificados de un vistazo en el explorador de archivos. Si preparo algunos archivos, generalmente es antes de la confirmación o si he terminado con ellos, por lo que no tengo ningún uso para que se coloreen normalmente.

Si agregamos color para cada tipo posible de estado de git, el explorador de archivos comenzará a verse como un árbol de Navidad y será muy confuso ver lo que realmente está sucediendo.

@jrieken Un informe de error más, ocurre en los últimos iniciados:

• Versión de VSCode: Code - Insiders 1.18.0-insider (82dcf9835265cd0a45ec135587ae2a82673f1c8f, 2017-10-20T04: 24: 25.632Z)
• Versión del sistema operativo: Windows_NT x64 10.0.15063

Básicamente, VS Code "olvida" de vez en cuando que algunos archivos se modifican y deben colorearse en consecuencia. Por ejemplo, tengo 6 archivos modificados en este momento. VS Code (correctamente) muestra el número "6" en el botón git. Pero, en el árbol de archivos del proyecto, solo veo UN archivo en amarillo, los otros cinco archivos parecen no haber sido modificados. Curiosamente, los 6 archivos están correctamente coloreados en la sección de editores abiertos.

@dseipp Podría ser opcional. Sin embargo, nunca verá el color "preparado" hasta que ponga los archivos en escena ... Así que ni siquiera se ve el 99% del tiempo, y no debería molestar a nadie ...

@ karabaja4 No estoy de acuerdo con que no tenga ningún uso. Hiciste el punto, que nunca usas / notas / necesitas coloración por etapas ...

El propósito del resaltado de color es que me permite encontrar archivos nuevos / modificados de un vistazo en el explorador de archivos. Si preparo algunos archivos, generalmente es antes de la confirmación o si he terminado con ellos, por lo que no tengo ningún uso para que se coloreen normalmente.

Entonces, incluso si se agrega esta función, no debería molestarlo ...

Ser capaz de ver archivos preparados ayuda a elegir lo que está a punto de cometer. Si hemos cambiado 100 archivos, entonces necesitamos agruparlos, podemos buscar en el árbol de archivos y ver fácilmente lo que está preparado, y detectar los que nos perdimos, para asegurarnos de que estén en la misma confirmación.

¿Cuántas veces ha cometido un puñado de archivos y luego se ha dado cuenta de que se perdió uno? Luego tiene 2 opciones, modificar su última confirmación para incluir los archivos perdidos o realizar una nueva confirmación. Cuando se trabaja con equipos, es más limpio y menos confuso tenerlos en el mismo compromiso.

En el punto intermedio, no importa si el archivo se ha agregado, modificado o cualquier otra cosa.

Para ser honesto, la forma en que Visual Studio Code maneja Git es sencilla y con errores. Árboles de archivos grandes, literalmente puede ver el goteo de colores a través de los archivos / carpetas. Deja caer el colorante al azar ...

Creo que todo el soporte de Git necesita una reescritura desde cero.

También me gustaría expresar mi apoyo por haber colocado archivos para colorear (opcional está bien siempre que pueda habilitarlo).

Aquí está mi flujo de trabajo: empiezo a trabajar en alguna característica / corrección de errores, llego al estado "OKish", lo que significa que el código funciona más o menos pero requiere algo de pulido / ajustes / limpieza o refactorización. En ese momento pongo en escena mis cambios. Luego, realice la limpieza y la refactorización. Si la refactorización falla o se vuelve demasiado complicada, simplemente vuelvo al estado por etapas.

Tener la capacidad de ver qué archivos estoy modificando actualmente es muy beneficioso, y cuando organizo los cambios no quiero perder toda esa información y llegar al árbol sin colores.

@vvs Estoy de acuerdo con que los archivos organizados no pierdan sus colores. Los colores deben permanecer hasta que se comprometan. Simplemente preferiría que el color en etapas mantenga los colores nuevos / modificados y que los colores en etapas adicionales sigan siendo opcionales.

Tal vez Staged pueda mantener los mismos colores, pero solo agregue algún tipo de resaltado o negrita para darle contraste.

Podría ser útil mirar el estado de la técnica. No recuerdo haber visto el indicador por etapas, pero tal vez los tiempos hayan cambiado.

¿Son realmente necesarios los iconos del explorador de archivos para archivos modificados / sin etapas / ...? Tengo algunos problemas de atención, por lo que los colores y los iconos me distraen con mucha facilidad. ¿No podría ser opcional y estar deshabilitado de forma predeterminada? ¿Soy el único que se distrae con ellos?

Desde el punto de vista de la experiencia del usuario, a veces menos es más, y muchos no se molestarán en buscar la opción de deshabilitar estas cosas y seguirán sufriendo o incluso cambiando de editor. Creo que sería bueno pensar en esto y decidir si esto es realmente necesario para una mejor UX (que supongo que es el objetivo de estos íconos).

* No tuve tiempo para leer todos los comentarios sobre este tema, así que dígame si lo que estoy preguntando es algo que ya se discutió y me tomaré mi tiempo para leer todo lo antes posible para ponerme en línea con lo que fue dicho. Gracias.

Creo que sería bueno pensar en esto y decidir si esto es realmente necesario para una mejor UX (que supongo que es el objetivo de estos íconos).

https://github.com/Microsoft/vscode/issues/178#issuecomment -336960308 es por eso que tenemos colores e insignias por defecto. Estuvo de acuerdo en que hace que la interfaz de usuario esté un poco más desordenada, abierta a sugerencias que sean accesibles / inclusivas pero también pulidas y limpias.

@jrieken ¡ Gracias! ¿Puede indicarme el compromiso que introdujo las insignias? Intentaré encontrar algo que sea beneficioso para ambos problemas (tener dificultades para ver los colores o no saber para qué sirven y problemas de distracción).

@jrieken Tomemos una página de Xcode y hagamos las insignias más sutiles.

Las insignias son útiles para dar pistas a los novatos, pero se vuelve desordenado después de que se aprenden los colores.

Para deshacerse de las bicicletas, prefiero las insignias coloreadas en git.color.ignored (_izquierda_ arriba) porque tienen la misma importancia visual. Es decir, desvanecerte pero no desaparecer en caso de que te necesite.

Si implementamos insignias sutiles, las insignias de la barra lateral de Source Control deberían actualizarse para mantener la coherencia.

Cualquiera que sea la dirección en la que se dirija la discusión sobre la insignia, ¿podría el diseño de la insignia al menos ser coherente con los de la barra lateral de Git? Se siente un poco desarticulado tener un diseño para la barra lateral del Explorador y otro diferente para la barra lateral de Git.

Me gusta la sugerencia de una

Si implementamos insignias sutiles, las insignias de la barra lateral de Source Control deberían actualizarse para mantener la coherencia.

Eso sucederá, está en mi plan para octubre.

He actualizado https://github.com/Microsoft/vscode/issues/178#issuecomment -335511695 con las últimas capturas de pantalla y nombres de colores. Además, con la información privilegiada del mañana, mostraremos las mismas insignias en el viewlet de SCM, pero sin etiquetas de colores. Al igual que

Se ve mejor @jrieken - Gracias por su esfuerzo continuo. ¡Creo que las insignias se ven mucho mejor!

Sin embargo, ¿debería ser la insignia U ? Creo que la comunidad debería opinar. El U me hace pensar primero en updated . Sé que es untracked en terminología de Git, pero creo que A es más apropiado, especialmente para aquellos que no están familiarizados con los términos subyacentes, que U se rastrea. - Yo personalmente voto por A por agregado. Como en, se ha agregado a su repositorio.

Luego, soporte para staged (opcional a través de la configuración) y está bastante cerca 👍

@WadeShuler , ¿qué tal un signo de interrogación (?) Para sin seguimiento? No me gusta A ya que tiene una connotación diferente para git de la que se entiende aquí, al menos en mi mente.

Editar: Pero estoy de acuerdo en que U podría ser confuso.

Creo que estaría bien con un signo de interrogación. Sin embargo, no creo que Code
solo es compatible con Git, ¿verdad? No creo que debamos mirarlo visualmente en
el editor como "Git", pero más control de versiones en general.

Cualquiera que sea el caso, realmente no me gusta "U" jajaja

El martes 24 de octubre de 2017 a las 2:20 p.m. Peter Kahle [email protected]
escribió:

@WadeShuler https://github.com/wadeshuler , ¿qué tal un signo de interrogación?
(?) ¿Sin seguimiento? No me gusta A porque tiene una connotación diferente para
git de lo que se quiere decir aquí, al menos en mi mente.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Microsoft/vscode/issues/178#issuecomment-339084261 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AJHVkJJNzw89umFiPB0BmgQAZYJNXTHzks5svip7gaJpZM4GlYyH
.

Muy bien, debería ser agnóstico. ¿Pero "Desconocido para el sistema de control de versiones" como? tiene sentido para mi. Pero N (para Nuevo) también podría funcionar, y no puedo pensar en ninguna sobrecarga para ese, aunque estoy seguro de que alguien más lo hará.

Sí, @jrieken , ¡sus esfuerzos son muy apreciados! ¡Muy bien! Las insignias sutiles son una ventaja.

Estoy con @WadeShuler y @petkahl en querer cambiar la U a otra cosa. La 'N' o '?' trabaja. Sin embargo, me inclino hacia la N, ya que entonces sería 'N'ew y' M 'modificada.

¡Emocionado de ver cómo esto se une!

¿ workbench.colorCustomizations.git.color.ignored funciona para todos?
Estoy en 1.18.0-insider actualizado por última vez hoy y el color ignorado todavía no se recoge. Además, parece que "_deleted_" y "_conflict_" aún no funcionan ... tal vez con la actualización de mañana,
Pero lo que me molesta es el color ignorado. El nombre del archivo tiene el mismo aspecto que un archivo versionado, sin modificar, lo que significa que no se le aplica ningún color especial.
Nota: El repositorio en la captura de pantalla no tiene ningún archivo de seguimiento. Todos los archivos están sin seguimiento. Una vez que elimino "_shared.module.ts_" de .gitignore , aparece en marrón (mi configuración de color sin seguimiento).

¿Debería la insignia ser U? Creo que la comunidad debería opinar. La U me hace pensar primero en actualizar. Sé que no se rastrea en la terminología de Git

Hemos estado usando 'U' antes, este no es el tema correcto para discutir qué es mejor, pero creo que los usuarios de git conocen la terminología y, para otros proveedores de SCM, se pueden / deben usar otras letras / íconos (y ese es el caso hoy).

Esta función no se ha agregado y he estado activo en este hilo desde
empezó a avanzar. He mencionado la insignia "U" desde el principio.

Este hilo trata sobre el desarrollo y la limpieza de toda la función, ya que
es nuevo. Si el color de fuente, el estilo de la insignia y los colores de la insignia son aceptables
para discutir en este hilo, entonces también lo son las letras.

Entonces, ¿en qué otro lugar, fuera de este hilo, hemos estado usando "U"?

Entonces, ¿en qué otro lugar, fuera de este hilo, hemos estado usando "U"?

Verifique estable, no información privilegiada, y el viewlet SCM con git. Utiliza una U para u ntracked archivos.

@WadeShuler @jrieken El viewlet SCM actual (1.17.2) marca un _archivo sin seguimiento_ con una U gris y un _archivo agregado_ con una A verde . git status muestra _archivos agregados (por etapas )_ en verde ANSI .

Entonces entiendo la confusión con una U verde para un _archivo sin seguimiento_. También preveo que me dolerán los ojos por la mezcla de las U verdes con

Atom colorea los archivos nuevos sin seguimiento y en etapas como verde , y Xcode marca los archivos agregados como A siempre que sea un archivo nuevo. Ambos nunca me molestaron en lo más mínimo (pero una U verde sí).

Así que estaré a favor de usar A verdes para archivos nuevos sin seguimiento y preparados.

Continuemos con la 'U' vs 'A' vs '?' discusión en https://github.com/Microsoft/vscode/issues/36912. Gracias.

Estoy de acuerdo. Creo que es mejor continuar con las letras que se utilizan hoy en la interfaz. No me gusta la 'U' también, pero creo que esto está un poco fuera del alcance de esta solicitud de función. Si esto cambió, debería cambiar en todo el programa.

De acuerdo, este es un hilo enorme y solo tengo tiempo para leerlo, así que solo diré aquí: espero que haya una configuración para deshabilitar esto. Prefiero todos los nombres de archivo del mismo color y cuando necesito ver su estado, escribo git status . :-)

¿Este producto está abandonado? Parece ser.

Actualmente, list.activeSelectionForeground parece tener prioridad sobre el estilo de estado de git, por lo que los colores de estado de git no se pueden ver en el archivo seleccionado. Encuentro útil tener esta información, incluso en el archivo seleccionado actualmente. ¿Alguna posibilidad de que el estilo de estado de git tenga prioridad cuando explorer.decorations.colors es verdadero?
Este comportamiento se observó en personas con información privilegiada 1,18 8dfa696.

Actualmente, list.activeSelectionForeground parece tener prioridad sobre el estilo de estado de git, por lo que los colores de estado de git no se pueden ver en el archivo seleccionado.

De hecho, lo mismo aquí en los últimos iniciados (recién actualizados). Cuando hago clic en el nombre del archivo en el árbol del proyecto, el color de la entrada del archivo cambia (por ejemplo, de amarillo / modificado a neutral). También creo que este es un comportamiento bastante confuso. El color del archivo no debe cambiar cuando el usuario hace clic en el archivo.

Por cierto, el mismo problema con la lista de archivos abiertos, cuando hace clic en el archivo allí, el color de estado de git se reemplaza por el color de selección neutral.

Por cierto, el mismo problema con la lista de archivos abiertos, cuando hace clic en el archivo allí, el color de estado de git se reemplaza por el color de selección neutral.

Bueno, se hizo a propósito porque el color de primer plano de selección a menudo entra en conflicto con los colores de decoración. Agregar más colores, como git.untrackedSelectedForeground y git.untrackedFocusedForeground no nos pareció muy atractivo. Por lo tanto, dejamos que el color de selección gane cuando se selecciona un elemento y tiene el foco.

Atom no parece tener ningún problema con eso ...

No hay necesidad de nuevas configuraciones ... Los temas se actualizarán para adaptarse si el color de fondo del elemento seleccionado interfiere. Aquellos que no lo hagan, la comunidad decidirá no usar esos temas.

No lo he comprobado, pero espero que las "insignias" (es decir: U, M), no sean todavía archivos svg. Deben ser solo texto sin formato que se pueda diseñar / colorear.

Honestamente, VSCode debería haber ido con hojas de estilo para estas cosas en lugar de configuraciones de configuración torpes. Complicó demasiado un proceso bastante simple.

@WadeShuler Hay selección y enfoque y, como veo un cursor de editor en tu captura de pantalla, creo que tu elemento solo está seleccionado, no enfocado. De hecho, no veo una diferencia en Atom entre seleccionado y enfocado. Así es en VS Code

seleccionado pero no enfocado

seleccionado y enfocado

@jrieken He verificado dos yellow en la ventana izquierda del explorador de archivos. En su segunda captura de pantalla, el color red se pierde de test.foo , que es el problema.

Probé los temas Atom oscuros y claros predeterminados, así como otros 3 temas. Mi valor predeterminado (como ves en mi SS) es Seti (tanto la interfaz de usuario como el tema). No puedo hacer que Atom elimine el color yellow del explorador de archivos, sin importar lo que haga. Atom versión 1.21.2.

Seleccionado

Seleccionado y enfocado

Fuera de la caja, VS Code debería preservar el color del estado de git independientemente de los estados seleccionados o enfocados.

Si su problema son los temas, no es su problema. Esa es la responsabilidad de los desarrolladores de temas actualizar y acomodar.

En una nota al margen: no he revisado los últimos datos internos ni he visto el código, pero los archivos git ignored deben usar opacity no un color de fuente, por lo que siempre es x más oscuro que los archivos normales, independientemente de su color.

@WadeShuler, gracias por sus comentarios sobre cómo los administradores de temas deben manejar sus negocios. ¿Cómo se atreve el equipo de VSCode a proporcionar una API para ayudarlos a hacer eso? ¡Esos desarrolladores perezosos!

@fernandofleury Nadie dijo nada sobre no proporcionar a los administradores de temas una API para administrarlos. Mi publicación no decía nada por el estilo. Entonces, su comentario sarcástico es simplemente inválido e injustificado.

@jrieken dijo:

Bueno, se hizo a propósito porque el color de primer plano de selección a menudo entra en conflicto con los colores de decoración.

Yo dije:

Si su problema son los temas, no es su problema. Esa es la responsabilidad de los desarrolladores de temas actualizar y acomodar.

El problema sería un conflicto entre el color de primer plano (en realidad, es un color de fondo) del elemento del árbol de archivos / carpetas (normal, seleccionado, enfocado) y las opciones de color de fuente para los diversos estados de git.

Esto _ sería_ responsabilidad de los desarrolladores de temas. Deben elegir tanto los colores de primer plano de los elementos en el árbol como los colores de fuente para los distintos estados de git para que no entren en conflicto.

Por ejemplo: un desarrollador de temas tiene ThemeX y su color de fuente para los elementos del árbol de archivos del explorador es yellow . Bueno, su color de fuente predeterminado entraría en conflicto con el color de estado predeterminado yellow git. Ya no podría saber qué archivos se modifican. ¡Así que esto sería responsabilidad de los desarrolladores del tema! - Lo mismo ocurre con el color de fondo de los elementos seleccionados / seleccionados en el árbol de archivos del explorador frente a los colores de fuente de los estados de git.

¿Se pospone esto ahora?

@IljaDaderko No lo creo ya que aparece en la próxima nota de lanzamiento v1.18 de la próxima versión estable. La pregunta podría ser más, ¿se cerrará o hay todavía más trabajo por hacer?

@IljaDaderko VSCode v1.18 ya está disponible e incluye los cambios discutidos aquí.

¿Se supone que los colores de archivo ignorados son parte de la actualización v1.18? Los documentos dicen que gitDecoration.ignoredResourceForeground se puede usar para colorear archivos ignorados, pero hasta ahora no he podido ver que eso afecte a nada. Sin embargo, la coloración modificada / sin seguimiento funciona muy bien. Esto es en la versión 1.18.0 estable de Windows.

Lo mismo aquí (sobre el color ignorado). Tampoco me ha funcionado desde que comenzó toda esta implementación de Git. Usando Insiders.
Todo lo que hace gitDecoration.ignoredResourceForeground es ignorar los archivos ignorados de colorear :)

Me está funcionando y se ve ESPECTACULAR.

Finalmente está aquí 🥇

@arxpoetica Esto es lo que obtengo:

¿Cómo puede funcionar para algunos y no para otros? No lo entiendo. Es solo esa configuración gitDecoration.ignoredResourceForeground
¿Soy el único para el que no funciona? ¿De verdad nadie más? :) Oh, y @Shurelia
¿Alguien más (nosotros, los usuarios) ha probado realmente la configuración del color ignorado antes de decir que funciona?

Sistema operativo: Windows 10 PRO (1709)
VSCode: 1.19.0-insider (recién actualizado antes)
Lo mismo en mi computadora portátil del trabajo y en la computadora de escritorio de mi hogar.

¿Está en Insiders? ¿Como puedo usar lo?

¡Felicidades a todos!

@nkkollaw Tanto en 😎 internos como en estable (1.18)

@MrCroft Discuta los problemas de git-ignore aquí: https://github.com/Microsoft/vscode/issues/37857

Como hemos enviado esta función en nuestra última versión estable, es hora de cerrar y bloquear este problema. Cree nuevos problemas para discusiones de temas e informes de errores. Los problemas relacionados con esta área están etiquetados con la etiqueta file-decorations .

¡A todos, gracias por los excelentes y continuos comentarios que hicieron de esta función lo que es!

Para resumir y repetir mi comentario anterior .

Un par de cosas

• Por defecto hay una combinación de color y bagde.
  
  
  
  • habilitar / deshabilitar iconos con: "explorer.decorations.badges": true|false
  
  
  • habilitar / deshabilitar colores con "explorer.decorations.colors": true|false
  
  
• Los colores se muestran en el árbol de archivos, la sección de editores abiertos y en el viewlet de SCM
• Hay tres colores para empezar. Puede personalizarlos en la configuración workbench.colorCustomizations . Los colores son gitDecoration.modifiedResourceForeground ,
  gitDecoration.deletedResourceForeground ,
  gitDecoration.untrackedResourceForeground ,
  gitDecoration.ignoredResourceForeground , y
  gitDecoration.conflictingResourceForeground