El estado de Git tarda mucho en completarse


85

Estoy usando gitpara administrar archivos en un directorio local en una máquina con Windows; no hay red involucrada aquí, no estoy presionando o tirando hacia / desde otra máquina. Mi directorio tiene quizás 100 archivos, todos los archivos de prueba, bastante pequeños. Cuando corro git status, suele tardar entre 20 y 30 segundos en completarse. ¿Esto es normal? ¿Hay algo que pueda hacer para acelerarlo, o una mejor manera de ver cuál es el estado de mi repositorio (archivos modificados, archivos sin seguimiento, etc.)? Otros gitcomandos parecen completarse mucho más rápido.


¿Qué versión de git estás usando? Considere pedir ayuda en msysGit Google Group, o en la lista de correo de git (git [at] vger.kernel.org, no necesita suscribirse), tal vez este sea un error en git.
Jakub Narębski

Respuestas:


127

¿Has probado git gc ? Esto limpia cruft del repositorio de git.


3
Esto parece haber funcionado. Sin embargo, estoy muy sorprendido de que después de solo un par de confirmaciones, el repositorio tenga tantas cosas que se pueden limpiar, ¡gracias!
Matt McMinn

4
Jeje, acabo de ejecutar el comando git statususando el timecomando y obtuve un tiempo "real" de 30.464s. Entonces corrió git gca continuación, time git statusuna vez más, y consiguió un tiempo real de 35.409s. Bastante extraño.
RyanScottLewis

14
Esto me arregló de 33 segundos a menos de 1 segundo para la mayoría de mis repositorios. Sería bueno si Git le dijera que haga esto cuando comience a llegar a ese punto. Nunca supe que era necesario.
XP84

Cuando se ejecuta git statusvarias veces seguidas, las ejecuciones posteriores toman solo una fracción de la primera. Entonces, si está ejecutando git status, una git gcy git statusotra vez, se espera que funcione muy rápido.
kiewic

7

En un problema similar, descubrí que tener un repositorio de git en un directorio debajo de mi repositorio de git existente causaba una ralentización masiva.

Moví el repositorio de git secundario a otro lugar y ahora la velocidad es rápida.


Agrego un problema similar. Lo que sucedió es git init en un subdirectorio. El problema de eso es entonces, subdir está un poco oculto (necesitas hacer git status adentro para ver los cambios) pero supongo que git todavía está tratando de calcularlos. Ignoro el subdirectorio y todo está bien ahora.
mb14

6

¿Está utilizando algún tipo de software de protección antivirus? Quizás eso esté interfiriendo con las cosas. gites muy rápido para mí en Windows con repositorios de miles de archivos.


1
Sí, TrendMicro OfficeScan por mandato del empleador. Maté el escáner de virus, los mismos resultados con el estado de git.
Matt McMinn

1
Otra variante de este tema es el software de cifrado sobre la marcha, como Credant, que puede hacer que su caja sea notablemente más lenta.
Don Branson

Este fue el problema para mí. El antivirus Kaspersky desactivado y el estado volvió a ser <1 segundo.
Robin Winslow

5

¿Ha intentado reempacar? git-repack .

De lo contrario, intente duplicar el directorio y eliminar la carpeta .git en el directorio duplicado. Luego, cree un nuevo directorio git y vea si todavía es lento.

Si todavía es lento, entonces parece un problema de sistema o hardware. Git finaliza el estado de cientos de archivos por mí en menos de 5 segundos.


repack pareció ayudar: después de ejecutarlo, ejecuté el estado y regresó de inmediato. Sin embargo, esperé unos segundos y volví a ejecutar el estado, y me tomó 30 segundos. Intenté duplicar el directorio y tuve el mismo problema.
Matt McMinn

Mmmm interesante. ¿Tiene un disco externo? ¿O una memoria USB? Intente copiar el repositorio de allí y vea si hay alguna diferencia. Es posible que haya un problema con la unidad en la que se encuentra actualmente.
thedz

No hay diferencia en una unidad USB.
Matt McMinn

Eso es realmente extraño. Todo lo que realmente puedo decir en este momento es que no lo sé. Puede intentar copiar su repositorio y probarlo en la computadora de otra persona; eso debería, al menos, decirle si es un problema local en su sistema.
thedz

4

Por alguna razón git status es particularmente lento después de mover o copiar la carpeta del repositorio a una nueva ubicación.

En este caso, las ejecuciones posteriores suelen ser más rápidas.


1
¿Hay alguna forma de evitar esta lentitud en la primera ejecución? Probé git gc, pero no ayudó. No es un problema ya que solo ocurre la primera vez después de copiar los archivos.
franksands

No conozco una forma de evitar la lentitud inicial, pero si hubiera algún comando que pudiera hacerlo, probablemente estaría haciendo lo mismo que el git statuscomando inicial , por lo que probablemente tomaría la misma cantidad de tiempo en completarse.
DanJAB

4

Mi git statusfue muy lento (hasta un minuto), porque el .gitignorearchivo global estaba ubicado en mi perfil de usuario de Windows, que estaba almacenado en un recurso compartido de red inaccesible.

git config --global core.excludesfile
mostró algo como \\Nxxxx0\User\Username\Eigene Dateien\gitignore_global.txt

Por alguna razón \\Nxxxx0era inaccesible y mi perfil de usuario se cargó desde un sistema de respaldo\\Nxxxxx1 . Me tomó algún tiempo darme cuenta de eso, porque generalmente mi perfil de usuario está vinculado a una letra de unidad mediante un script de inicio de empresa y acceder a esa letra de unidad funcionaba como de costumbre. No estoy seguro de por qué git-config usó el recurso compartido de red y no la letra de la unidad (probablemente un yo más joven tiene la culpa)

Después del fraguado
git config --global core.excludesfile $HOME/Eigene\ Dateien/gitignore_global.txt
git statusvolvió a la velocidad normal.


3

Correr me git fsckha resuelto este problema en el pasado.


3

Para mí, la lentitud se debió a tener muchos archivos sin seguimiento (archivos temporales y de salida de scripts) en ejecución git status -uno, lo que excluye los archivos sin seguimiento, se ejecutó mucho más rápido y cumple con mis requisitos


1

El problema para mí fue que tenía muchos repositorios diferentes clonados en mi disco duro local, mientras más repositorios tenga, más tiempo llevará ejecutar comandos como git status.

Simplemente eliminé muchos de los repositorios que ya no necesitaba localmente, y mi estado de git pasó de 1 minuto ~ a 5 segundos.

No puedo ver ninguna respuesta similar a esta aquí.


1
No creo que esto pueda afectar el estándar git statusque ejecuta en un directorio de ninguna manera. Si sus repositorios están extraídos en diferentes directorios, solo puede ejecutar git statusuno de ellos a la vez. Podría ser una historia diferente si sus repositorios de git se superponen, pero de todos modos esa es una mala idea.
Hubert Grzeskowiak

@HubertGrzeskowiak definitivamente puede. Estaban por todas partes en diferentes lugares de mi disco duro para mí, pero afectó enormemente mis tiempos de carga al escribir git status. Después de eliminar los repositorios duplicados, inmediatamente se volvió más rápido de varios minutos a 5 segundos.
Jack Perry

1

Otro aspecto git statusque se mejorará (en Git 2.14.x / 2.15, Q4 2017) es cuando también muestra archivos ignorados ( git status --ignored)

" git status --ignored", al notar que un directorio sin ninguna ruta rastreada se ignora, aún enumera todas las rutas ignoradas en el directorio, lo cual es innecesario.
La ruta de código se ha optimizado para evitar esta sobrecarga.

Consulte la confirmación 5aaa7fd (18 de septiembre de 2017) de Jameson Miller ( jamill) .
(Combinado por Junio ​​C Hamano - gitster- en el compromiso 075bc9c , 29 de septiembre de 2017)

Mejorar el rendimiento de git status --ignored

Mejore el rendimiento de la lógica de listado de directorios cuando quiere listar directorios ignorados no vacíos. Para mostrar directorios ignorados no vacíos, la lógica existente iterará recursivamente a través de todo el contenido de un directorio ignorado.
Este cambio introduce la optimización para dejar de iterar a través del contenido una vez que encuentra el primer archivo. Esto puede tener una mejora significativa en el rendimiento de 'git status --ignored' en repositorios con una gran cantidad de archivos en directorios ignorados.

Para ver un ejemplo de la diferencia de rendimiento en un repositorio de ejemplo con 196 000 archivos en 400 directorios ignorados:

| Command                    |  Time (s) |
| -------------------------- | --------- |
| git status                 |   1.2     |
| git status --ignored (old) |   3.9     |
| git status --ignored (new) |   1.4     |

Para obtener más mejoras (establecidas en Git 2.17, Q2 2018), consulte esta respuesta .


Ejemplo totalmente aleatorio aquí: node_modulespodría verse afectado por este cambio de rendimiento. Solo tal vez.
Seth Battin

1

Las versiones anteriores de git tienen un problema de rendimiento con el estado de git; consulte Formas de mejorar el rendimiento del estado de git para obtener más información.

git 2.13 tiene 1 corrección y 2.17 más. Pasé de 2.7 a 2.23 y resolvió el estado lento. Hay otra mejora prevista para 2.24 pronto.


0

En mi caso, la lentitud se debió a que se ejecutaba git statuscomo un usuario diferente al propietario de los archivos del proyecto.

Si bien no es aplicable en todos los casos, un simple chownpara su usuario actual puede hacer el truco.


-13

Intente comenzar con un nuevo clon de su pago.

git clone myrepo mynewrepo

y luego hacer git status en mynewrepo.

Alternativamente, y si eres más valiente, limpia la basura de tu caja actual.

git clean -dfx

Esto evita que git tenga que escanear un conjunto (posiblemente grande) de archivos ignorados o no registrados.


No creo que eliminar todos los archivos ignorados (lo que hace git clean) ayude, ya los está ignorando. Lo más probable es que al ejecutar git clean se borren todos los archivos de configuración, etc., etc. Y este comando no se puede deshacer. Volver a clonar (primero guardar su antiguo repositorio en caso de que lo necesite) es mucho mejor que ejecutar git clean y tiene el mismo efecto.
XP84

5
Tengo que no estar de acuerdo con esta respuesta, ejecutar git clean -dfx puede romper cosas.
Marcel Valdez Orozco
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.