tortoise - Git Bash es extremadamente lento en Windows 7 x64

tortoise git (23)

He estado usando Git tanto en Windows como en Ubuntu durante el desarrollo de un pequeño proyecto, frecuentemente alternando entre los dos. El problema es que Git Bash constantemente se vuelve lento.

Cuando digo lento, me refiero a que la ejecución de cd tarda entre 8 y 25 segundos, la ejecución de los comandos git toma de 5 a 20 segundos, y ls puede llevar hasta 30 segundos a veces. No hace falta decir que esto no es divertido, por no decir improductivo. Sé que Git es más lento en Windows, pero esto es ridículo.

La única solución que funcionó, temporalmente, para mí ha sido deshabilitar mi conexión de red (como se sugiere en esta respuesta ), iniciar Git Bash y luego volver a conectar. A veces continúa ejecutándose rápidamente durante días después de hacer eso, pero el rendimiento siempre se degrada con el tiempo. He rastreado el grupo de discusión msysgit, el desbordamiento de pila, la lista de problemas de msysgit, etc. por semanas, pero no he podido encontrar soluciones que funcionen.

Hasta ahora, he intentado:

Agregar carpetas de Git y proyectos a la lista de exclusión del escáner de virus
Desactivar completamente mi escáner de virus (Kaspersky IS 2011)
Asegurarse de que Outlook no se está ejecutando (Outlook 2007)
Apagando todas las demás aplicaciones
Ejecutando Git Bash como administrador
Deshabilitar la conexión de red, iniciar Git Bash y mantener la conexión deshabilitada
Deshabilitar la conexión de red, iniciar Git Bash, volver a habilitar la conexión (funciona solo ocasionalmente)
Corriendo git gc
Y combinaciones de los anteriores.

Leí que un par de personas tuvieron éxito deshabilitando la finalización de Bash, pero lo ideal sería mantenerlo activo. La versión de msysgit es 1.7.3.1-preview20101002 y el sistema operativo es Windows 7 x64. Ejecutar las mismas cosas en Linux es, como era de esperar, rápido como un rayo. Yo usaría Linux exclusivamente, pero también necesito ejecutar cosas en Windows (ciertas aplicaciones, pruebas, etc.).

¿Alguien ha encontrado un problema similar? Si es así, ¿cuál fue el problema subyacente y cuál fue la solución (si existe)?

Esto se extiende más allá de los repositorios de Git, pero solo como referencia, los repositorios con los que he estado usando Git han sido bastante pequeños: de 4 a 50 archivos como máximo.

¿Tienes información de Git que se muestra en tu mensaje de Bash? Si es así, tal vez, sin darse cuenta, está haciendo demasiado trabajo en cada comando. Para probar esta teoría, pruebe el siguiente cambio temporal en Bash:

export PS1=''$''

Además de estas otras respuestas, he acelerado proyectos con múltiples submódulos mediante la búsqueda de submódulos paralelos (desde Git 2.8 a principios de 2016).

Esto se puede hacer con git fetch --recurse-submodules -j8 y configurarlo con git config --global submodule.fetchJobs 8 , o por muchos núcleos que tenga / quiera usar.

Como muchos dijeron, esto se debe a que el stash es un script de shell en Windows pero desde git 2.18.0, el instalador de Windows tiene una opción para una característica experimental de una versión mucho más rápida (~ 90%) de stash https://github.com/git-for-windows/build-extra/pull/203

Como se señaló en las respuestas de Chris Dolan y Wilbert, PS1 te hace más lento .

En lugar de deshabilitar completamente (según lo sugerido por Dolan) o usar el script ofrecido por Wilbert, uso un "tonto PS1" que es mucho más rápido.

Utiliza (git symbolic-ref -q HEAD || git rev-parse --short HEAD) 2> /dev/null :

PS1=''/033[33m/]/w /n/[/033[32m/]$((git symbolic-ref -q HEAD || git rev-parse -q --short HEAD) 2> /dev/null) /[/033[00m/]# ''

En mi Cygwin, esto es más rápido que la respuesta "fast_Git_PS1" de Wilbert : 200 ms en lugar de 400 ms, por lo que elimina un poco de su lentitud.

No es tan sofisticado como __git_ps1 ; por ejemplo, no cambia el indicador cuando ingresas en el directorio .git, etc., pero para el uso diario normal es lo suficientemente bueno y rápido.

Esto se probó en Git 1.7.9 (Cygwin, pero debería funcionar en cualquier plataforma).

En mi caso, el acceso directo de Git Bash se estableció en Start in:%HOMEDRIVE%%HOMEPATH% (puede verificarlo haciendo clic con el botón derecho en Git Bash y seleccionando las propiedades). Esta fue la unidad de red.

La solución es hacer que apunte a %HOME% . Si no lo tiene, puede configurarlo en las variables de entorno y ahora Git Bash debería ser muy rápido.

En mi caso, en realidad fue un antivirus Avast que llevó a Git Bash e incluso a PowerShell a ser realmente lento.

Primero intenté deshabilitar Avast durante 10 minutos para ver si mejoraba la velocidad y lo hizo. Luego, agregué todo el directorio de instalación de Git Bash como una excepción en Avast, para lectura, escritura y ejecución. En mi caso, fue C:/Program Files/Git/* .

En una extensión de la respuesta de Chris Dolan, usé la siguiente configuración alternativa de PS1 . Simplemente agregue el fragmento de código a su ~ / .profile (en Windows 7: C: /Users/USERNAME/.profile).

fast_git_ps1 () { printf -- "$(git branch 2>/dev/null | sed -ne ''/^/* / s/^/* /(.*/)/ [/1] / p'')" } PS1=''/[/033]0;$MSYSTEM:/w/007 /033[32m/]/u@/h /[/033[33m/w$(fast_git_ps1)/033[0m/] $ ''

Esto conserva el beneficio de un shell de color y la visualización del nombre de la rama actual (si está en un repositorio Git), pero es significativamente más rápido en mi máquina, de ~ 0.75 sa 0.1 s.

Esto se basa en esta entrada de blog .

Encontré que la unidad de red era el problema de rendimiento. HOME estaba apuntando a una red lenta. No podría anular HOMEDRIVE pero eso no es un problema por lo que he visto.

Establezca la variable de entorno haciendo clic con el botón derecho en su computadora en el escritorio -> propiedades -> Configuración avanzada del sistema -> Variables de entorno, sección Agregar a variables de usuario

HOME=%USERPROFILE%

Estaba teniendo el mismo problema, tanto en Git Bash como en Git GUI. Ambos programas suelen ejecutarse bien, pero luego se desaceleraron aleatoriamente a un rastreo, y no pude averiguar por qué.

Como resultado, fue Avast. Avast ha causado que sucedan cosas raras en varios programas (incluidos los programas que escribo), así que lo deshabilité por un segundo y, efectivamente, Bash ahora se ejecuta tan rápido como lo hace en Linux. Acabo de agregar la carpeta de archivos de programa Git ( C:/Program Files/Git ) a la lista de exclusión de Avast, y ahora se ejecuta tan rápido como lo hace en Linux.

Y sí, me doy cuenta de que el software antivirus no era el problema en la publicación original, pero lo pondré aquí en caso de que sea útil para alguien.

He encontrado el mismo problema al ejecutar Git para Windows (msysgit) en Windows 7 x64 como una cuenta de usuario limitada durante bastante tiempo.

Por lo que he leído aquí y en otros lugares, el tema común parece ser la falta de privilegios administrativos y / o UAC. Ya que UAC está apagado en mi sistema, la explicación de que está tratando de escribir / borrar algo en el directorio de archivos del programa tiene más sentido para mí.

En cualquier caso, he resuelto mi problema instalando la versión portátil de Git 1.8 con zipinstaller. Tenga en cuenta que tuve que descomprimir el archivo de distribución .7z y volver a empaquetarlo como un archivo ZIP para que el programa de instalación de zip funcione. También tuve que agregar manualmente ese directorio a la ruta de mi sistema.

El rendimiento está bien ahora. A pesar de que está instalado en el directorio Program Files (x86) , para el cual no tengo permisos como usuario limitado, no parece tener el mismo problema.

Lo atribuyo al hecho de que la versión portátil es un poco más conservadora en el lugar donde escribe / elimina archivos, lo que probablemente sea el caso, o a la actualización de 1.7 a 1.8. No voy a tratar de precisar cuál es la razón, basta con decir que ahora funciona mucho mejor, incluido Bash.

Mi directorio de inicio de Windows está en la red, y sospeché que los comandos de Git Bash estaban mirando primero allí. Efectivamente, cuando miré $ PATH, enumera / h / bin primero, donde / h es un recurso compartido en un servidor de archivos de Windows, aunque / h / bin no existe. Edité / etc / profile y comenté el comando de exportación que lo pone primero en $ PATH:

#export PATH="$HOME/bin:$PATH"

Esto hizo que mis comandos se ejecutaran mucho más rápido, probablemente porque Git Bash ya no está buscando en la red los archivos ejecutables. Mi / etc / profile era c: / Archivos de programa (x86) / Git / etc / profile.

Nada de lo anterior fue capaz de ayudarme. En mi escenario, el problema se mostraba así:

Cualquier comando ll fue lento (tardó unos 3 segundos en ejecutarse)
Cualquier comando ll subsiguiente se ejecutó instantáneamente, pero solo si dentro de los 45 segundos del comando ls anterior .

Cuando se trató de depurar con Process Monitor , se encontró que antes de cada comando había una solicitud de DNS.

Tan pronto como deshabilité mi firewall (Comodo en mi caso) y dejé que el comando ejecutara, el problema desapareció. Y no está regresando cuando el firewall fue encendido nuevamente. Con la primera oportunidad, actualizaré esta respuesta con más detalles sobre qué proceso estaba haciendo una solicitud de DNS de bloqueo y cuál era el objetivo.

BR, G

Parece que la desinstalación completa, el reinicio (la cura clásica de Windows) y la reinstalación de Git fue la cura. También borré todos los archivos de configuración de bash que quedaron (se crearon manualmente). Todo es rápido de nuevo.

Si por alguna razón no es posible (o deseable) reinstalar, entonces definitivamente intentaría cambiar la variable PS1 referenciada en la respuesta de Chris Dolan ; resultó en aceleraciones significativas en ciertas operaciones.

Puede acelerar significativamente Git en Windows ejecutando tres comandos para configurar algunas opciones de configuración:

git config --global core.preloadindex true git config --global core.fscache true git config --global gc.auto 256

Notas:

core.preloadindex realiza operaciones del sistema de archivos en paralelo para ocultar la latencia (actualización: habilitada de forma predeterminada en Git 2.1)
core.fscache soluciona los problemas de UAC para que no necesite ejecutar Git como administrador (actualización: habilitada de forma predeterminada en Git para Windows 2.8)
gc.auto minimiza la cantidad de archivos en .git /

Resolví mi problema lento de Git en Windows 7 x64 iniciando cmd.exe con "Ejecutar como administrador".

Respuestas combinadas:

Wilbert''s - qué información incluir en PS1
sinelaw''s - (<branch_name>) o (<sha>)

# https://unix.stackexchange.com/questions/140610/using-variables-to-store-terminal-color-codes-for-ps1/140618#140618 # https://unix.stackexchange.com/questions/124407/what-color-codes-can-i-use-in-my-ps1-prompt # /033 is the same as /e # 0;32 is the same as 32 CYAN="$(echo -e "/e[1;36m")" GREEN="$(echo -e "/e[32m")" YELLOW="$(echo -e "/e[33m")" RESET="$(echo -e "/e[0m")" # https://.com/questions/4485059/git-bash-is-extremely-slow-in-windows-7-x64/19500237#19500237 # https://.com/questions/4485059/git-bash-is-extremely-slow-in-windows-7-x64/13476961#13476961 # https://.com/questions/39518124/check-if-directory-is-git-repository-without-having-to-cd-into-it/39518382#39518382 fast_git_ps1 () { git -C . rev-parse 2>/dev/null && echo " ($((git symbolic-ref --short -q HEAD || git rev-parse -q --short HEAD) 2> /dev/null))" } # you need /] at the end for colors # Don''t set /[ at the beginning or ctrl+up for history will work strangely PS1=''${GREEN}/u@/h ${YELLOW}/w${CYAN}$(fast_git_ps1)${RESET}/] $ ''

Resultado:

Sólo me resultó útil desactivar AMD Radeon Graphics (o Intel Graphics) en el Administrador de dispositivos.

Encontré la respuesta aquí: https://superuser.com/questions/1160349/git-is-extremely-slow-on-windows#=

Si bien su problema podría estar basado en la red, personalmente he acelerado mis llamadas locales de git status diez veces (más de 7 segundos a 700 ms) haciendo dos modificaciones. Esto está en un repositorio de 700 MB con 21,000 archivos y un número excesivo de archivos binarios grandes.

Uno es habilitar precargas de índice paralelo. Desde un símbolo del sistema:

git config core.preloadindex true
Esto cambió el time git status de time git status de 7 segundos a 2,5 segundos.

¡Actualizar!
Lo siguiente ya no es necesario. Un parche ha solucionado esto a partir de mysysgit 1.9.4
https://github.com/msysgit/git/commit/64d63240762df22e92b287b145d75a0d68a66988
Sin embargo, debe habilitar la corrección escribiendo
git config core.fscache true

También deshabilité el UAC y el controlador "luafv" (se requiere reiniciar). Esto deshabilita un controlador en Windows Vista, 7 y 8 que redirige los programas que intentan escribir en las ubicaciones del sistema y, en cambio, redirige los accesos a un directorio de usuarios.

Para ver una discusión sobre cómo esto afecta el rendimiento de Git, lea aquí: https://code.google.com/p/msysgit/issues/detail?id=320

Para deshabilitar este controlador, en regedit, cambie la tecla "inicio" en HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/luafv a 4 para deshabilitar el controlador. Luego, ponga UAC en su configuración más baja, "nunca notificar".

Si la desactivación de este controlador lo hace desconfiar (debería), se está ejecutando una alternativa en una unidad (o partición) diferente a la partición de su sistema. Al parecer, el controlador solo se ejecuta en el acceso a archivos en la partición del sistema. Tengo un segundo disco duro y veo resultados idénticos cuando lo ejecuto con esta modificación de registro en mi disco C como lo hago sin él en el disco D.

Este cambio lleva el time git status de time git status de 2.5 segundos a 0.7 segundos.

También es posible que desee seguir https://github.com/msysgit/git/pull/94 y https://github.com/git/git/commit/d637d1b9a8fb765a8542e69bd2e04b3e229f663b para ver qué trabajo adicional está en camino para problemas de velocidad en Windows .

Si usa Git desde cmd, intente ejecutarlo desde Git Bash. En cmd, git.exe es en realidad un contenedor que configura el entorno correcto cada vez que lo inicias, y solo entonces se inicia el git.exe real. Puede llevar hasta el doble de tiempo de lo requerido para hacer lo que usted quiere. Y Git Bash configura el entorno solo cuando comienza.

También puede obtener un aumento de rendimiento muy posterior cambiando la siguiente configuración de Git:

git config --global status.submoduleSummary false

Al ejecutar el simple comando de git status en Windows 7 x64, mi computadora tardó más de 30 segundos en ejecutarse. Después de que esta opción fue definida, el comando es inmediato.

Activar el rastreo de Git como se explica en la siguiente página me ayudó a encontrar el origen del problema, que podría diferir en su instalación: github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is-so-slow

También tuve problemas con la lentitud de git PS1, aunque durante mucho tiempo pensé que era un problema de tamaño de base de datos (gran repositorio) y estaba probando varios trucos de git gc , y estaba buscando otras razones, como usted. Sin embargo, en mi caso, el problema era esta línea:

function ps1_gitify { status=$(git status 2>/dev/null ) # <-------------------- if [[ $status =~ "fatal: Not a git repository" ]] then echo "" else echo "$(ps1_git_branch_name) $(ps1_git_get_sha)" fi }

Hacer el git status para cada línea de estado de línea de comando fue lento. Ay. Fue algo que escribí a mano. Vi que era un problema cuando probé el

export PS1=''$''

como se menciona en una respuesta aquí. La línea de comando era muy rápida.

Ahora estoy usando esto:

function we_are_in_git_work_tree { git rev-parse --is-inside-work-tree &> /dev/null } function ps1_gitify { if ! we_are_in_git_work_tree then ...

Desde la línea PS1 de con la rama y los colores actuales de git , funciona bien. De nuevo ten una línea de comandos rápida de Git.

Un compañero de trabajo que tenía problemas con Git en Windows (7) la checkout y el git status fueron rápidos, pero el git commit tomó mucho tiempo.

Todavía estamos tratando de encontrar la causa raíz de esto, pero la clonación del repositorio en una nueva carpeta solucionó su problema.

Vi una mejora decente al establecer core.preloadindex en true como se recomienda aquí .