Git Bash es extremadamente lento en Windows 7 x64

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

Cuando digo lento, quiero decir que la ejecución cddemora entre 8 y 25 segundos, los gitcomandos de ejecución demoran entre 5 y 20 segundos y, en lsocasiones , pueden tardar hasta 30 segundos. No hace falta decir que esto no es divertido, por no mencionar improductivo. Sé que Git es más lento en Windows, pero esto es ridículo.

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

Hasta ahora, he intentado:

• Agregar carpetas de proyectos y Git a la lista de exclusión del escáner de virus
• Desactivar completamente mi antivirus (Kaspersky IS 2011)
• Asegurarse de que Outlook no se esté ejecutando (Outlook 2007)
• Cerrar 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 lo anterior

Leí que un par de personas tuvieron éxito al deshabilitar la finalización de Bash, pero idealmente me gustaría mantener eso 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, muy rápido. 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 la hubo)?

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: ~ 4-50 archivos como máximo.

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 por defecto en Git 2.1)

• core.fscache corrige 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 el número de archivos en .git /

¿Tiene información de Git que se muestra en su solicitud de Bash? Si es así, tal vez sin querer esté haciendo demasiado trabajo en cada comando. Para probar esta teoría, intente el siguiente cambio temporal en Bash:

export PS1='$'

Mi directorio de inicio de Windows está en la red, y sospeché que los comandos de Git Bash estaban buscando allí primero. Efectivamente, cuando miré $PATH, aparece en /h/binprimer lugar, donde /hhay un recurso compartido en un servidor de archivos de Windows, a pesar de /h/binque no existe.
Edité /etc/profiley comenté el comando de exportación que lo coloca primero en $PATH:

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

Esto hizo que mis comandos se ejecuten mucho más rápido, probablemente porque Git Bash ya no busca ejecutables en la red. Mi /etc/profileera c:\Program Files (x86)\Git\etc\profile.

Encontré que la unidad de red era el problema de rendimiento. HOMEapuntaba a un recurso compartido de red lento. No pude anular, HOMEDRIVEpero eso no es un problema por lo que he visto.

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

HOME=%USERPROFILE%

En una extensión de la respuesta de Chris Dolan, utilicé la siguiente PS1configuración alternativa . 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 publicación de blog .

Si bien su problema puede estar basado en la red, personalmente he acelerado git statusdiez veces mis llamadas locales (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 paralelas. Desde un símbolo del sistema:

git config core.preloadindex true
Esto cambió time git statusde 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 ubicaciones del sistema y en su lugar redirige esos 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" HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/luafva 4 para deshabilitar el controlador. Luego, coloque 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. Aparentemente, el controlador solo se ejecuta con acceso a archivos en la partición del sistema. Tengo un segundo disco duro y veo resultados idénticos cuando se ejecuta con esta modificación del registro en mi disco C como lo hago sin él en el disco D.

Este cambio lleva time git statusde 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 marcha para problemas de velocidad en Windows .

Parece que desinstalar completamente Git, reiniciar (la cura clásica de Windows) y reinstalar Git fue la cura. También eliminé todos los archivos de configuración de bash que quedaron (se crearon manualmente). Todo vuelve a ser rápido.

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

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

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

Como se señaló en las respuestas de Chris Dolan y Wilbert, PS1 te ralentiza .

En lugar de deshabilitar completamente (como lo sugiere Dolan) o usar el script ofrecido por Wilbert, uso una "PS1 tonta" que es mucho más rápida.

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 frente a 400 ms, por lo que reduce un poco su lentitud inmediata.

No es tan sofisticado como __git_ps1, por ejemplo, no cambia el indicador cuando ingresa al 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).

También puede obtener un aumento de rendimiento muy subsiguiente al cambiar la siguiente configuración de Git:

git config --global status.submoduleSummary false

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

La activación del seguimiento de Git como se explica en la siguiente página me ayudó a encontrar el origen del problema, que puede diferir en su instalación: https://github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is-so- lento

Estaba teniendo el mismo problema, tanto en Git Bash como en Git GUI. Ambos programas solían funcionar bien, pero luego se ralentizaron aleatoriamente y no pude entender por qué.

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

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

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

Esto se puede hacer git fetch --recurse-submodules -j8y configurar con git config --global submodule.fetchJobs 8, o con la cantidad de núcleos que tenga / quiera usar.

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 inicia, y solo entonces inicia el git.exe real. Puede tomar hasta el doble de tiempo del necesario para hacer lo que desea. Y Git Bash configura el entorno solo cuando se inicia.

Solo desactivar AMD Radeon Graphics (o Intel Graphics) en Device Manager me ayudó.

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

Respuestas combinadas:

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

# /unix/140610/using-variables-to-store-terminal-color-codes-for-ps1/140618#140618
# /unix/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")"

# /programming/4485059/git-bash-is-extremely-slow-in-windows-7-x64/19500237#19500237
# /programming/4485059/git-bash-is-extremely-slow-in-windows-7-x64/13476961#13476961
# /programming/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:

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. Como UAC está apagado en mi sistema, la explicación de que está tratando de escribir / eliminar 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 instalador zip funcione. También tuve que agregar manualmente ese directorio a la ruta de mi sistema.

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

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

En mi caso, en realidad fue el antivirus Avast lo que llevó a Git Bash e incluso a PowerShell a ser muy 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 Leer, Escribir y Ejecutar. En mi caso eso fue C:\Program Files\Git\*.

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

• Cualquier llcomando era lento (tardaba unos 3 segundos en ejecutarse)
• Cualquier llcomando posterior se ejecutó al instante, pero solo si dentro de los 45 segundos desde el comando ls anterior .

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

Entonces, tan pronto como desactivé mi firewall (Comodo en mi caso) y dejé que el comando ejecutara, el problema desapareció. Y no regresa cuando el firewall se volvió a encender. Con la primera oportunidad, actualizaré esta respuesta con más detalles sobre qué proceso estaba haciendo una solicitud de bloqueo de DNS y cuál era el objetivo.

BR, G

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

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

También tuve problemas con la lentitud de git PS1, aunque durante mucho tiempo pensé que era un problema de tamaño de la base de datos (gran repositorio) e intenté varios git gctrucos y busqué otras razones, como tú. 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 statuspara cada línea de estado de la 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 estaba a la velocidad del rayo.

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 Post PS1 de Stack Overflow con git rama y colores actuales y funciona bien. Nuevamente tenga una línea de comando Git rápida.

Un compañero de trabajo mío tuvo problemas con Git en Windows (7) git status checkouty addfue rápido, pero git committardó años.

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

Como muchos dijeron, esto se debe a que stashes 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 integrada de stash mucho más rápida (~ 90%) - https: / /github.com/git-for-windows/build-extra/pull/203 .