Cade Bryant
A veces, en Visual Studio 2019, cuando se trabaja con un repositorio de Git, hacer clic con el botón derecho y seleccionar Deshacer cambios en Team Explorer no funciona como se esperaba. Si bien los cambios se deshacen, el ícono del archivo aún permanece bajo el encabezado Cambios.
Incluso si desaparece, muchas veces si luego corro git status desde la consola, el nombre del archivo se mostrará en la consola bajo changes not staged for commit.
Puedo arreglar esto fácilmente ejecutando git reset --hard. Aun así, es una molestia. ¿Alguna idea de lo que sucede debajo del capó de VS que hace que funcione (mal) de esta manera?
Según su descripción (deshacer no actualiza el estado del archivo, git reset --hard es una solución alternativa), esto suena como el siguiente problema:
https://developercommunity2.visualstudio.com/t/Undo-changes-with-new-git-experience-pre/1170228
La causa principal parece estar relacionada con los finales de línea:
Microsoft:
Así que nuestra sospecha es que tal vez
dotnet formatreescribió los finales de línea (y solo los finales de línea), así que ahoragit statusinforma que hay archivos modificados. Sin embargo, si intenta realizar el checkout-index, git en realidad no mutará nada. Sin embargo, el estado de git cree que hay cambios, porque el bloque de estadísticas lo lleva a creer que ha habido un cambio (ya que ha habido un cambio). Una forma de verificar esto es desde la línea de comandos o Visual Studio. Prepara todo (git add *) (puedes hacer esto desde Visual Studio haciendo clic con el botón derecho > escenario) git status (o, si está en Visual Studio, actualizará el estado automáticamente) Si los archivos desaparecen de la vista, entonces hay un final de línea problema, y git se ha dado cuenta de repente de que en realidad son el mismo archivo.
Reportero:
¡Sí! Poner todo en escena hizo que todos los archivos desaparecieran 🙂
Microsoft:
¡Fresco! ¡Así que esto es lo que sabemos! Para los cambios de solo EOL, los cambios de SHA no cambian. Aparentemente, Git los almacena internamente como solo LF. Ni el checkout ni el checkout-index sobrescribirán el archivo en el disco. Básicamente, dado que git es nuestra fuente de verdad aquí, obtenemos información engañosa. Sin embargo, creo que Git tal vez tomó la decisión correcta aquí con respecto al rendimiento. Dicho esto, esto es muy confuso desde la perspectiva de UX, por lo que evaluaremos esto. Estamos evaluando cómo mejorar este UX.
El problema aún está abierto, pero parece que se identificó la causa raíz. Por ahora, solo existe la solución.
-
+1: puedo confirmar que esta respuesta es correcta; simplemente organice cualquier archivo con un “cambio fantasma invisible”, y ese archivo desaparecerá “mágicamente” de la lista de archivos modificados (sin ser incluido en la lista de archivos preparados).
– Voluntad
2 de junio de 2021 a las 23:07
-
@Will puede confirmar, acabo de tener el mismo problema en la última versión de VS 2019. La puesta en escena de alguna manera hace que el archivo desaparezca. Confuso.
– Tomás Voracek
16 ago 2021 a las 8:30
-
Todavía no funciona en VS2022. ¿Por qué no estoy remotamente sorprendido?
– Neutrino
6 mayo 2022 a las 14:47
-
El truco de puesta en escena sigue funcionando incluso en las últimas versiones de VS2022 y Git.
– Tomás Voracek
29 de julio de 2022 a las 15:07
Tenía un archivo que se atascó en este estado. El problema era que la carcasa del archivo local no coincidía con la carcasa del archivo remoto, aunque la ortografía era la misma.
En mi caso, la operación estaba bloqueada porque tenía un Build/Debug en ejecución.
DConfort
Esto es lo que hice para que vstudio se comportara correctamente al hacer “Deshacer cambios” o al guardar el archivo en el disco. Si ejecuta el siguiente comando en un cmd Shell:
git config --global core.autocrlf false
Vstudio respetará esta configuración de git.