Git Bash es extremadamente lento en Windows 7 x64

436

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.

Géminis14
fuente
1
No para desanimarte, pero Cygwin es muy lento en x64, es mejor que lo pruebes en Windows XP de 32 bits.
ismail
2
posible duplicado de Msysgit bash es terriblemente lento en Windows 7
childno͡.de
55
En el mismo sistema, no fue lento hace medio año. Deben haber cambiado algo ...
Tomáš Zato - Restablecer a Mónica
2
En prácticamente todas las máquinas aquí: Kaspersky AV ralentiza masivamente git y "deshabilita" Kaspersky está roto, avp.exe todavía se ejecuta después de salir por completo. La reinstalación completa de kaspersky generalmente soluciona el último problema.
Peter
2
Vea la página wiki de msysgit sobre esto: github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is-so-slow
Drew Noakes

Respuestas:

409

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 /

shoelzer
fuente
No me ayudó, pero ayudó a exportar PS1 = '$' mencionado a continuación. Entonces sé para mí que el problema es la línea terminal.
Koshmaar
67
Configuraciones completamente inútiles en 2017 (git 2.12) porque todo esto está habilitado de forma predeterminada. Pero el imbécil todavía funciona lentamente como una mierda.
decir
2
Funciona muy bien en Windows 10 también. Bien hecho y gracias por este @shoelzer!
Joe
1
Limitar archivos a 256 puede causar algunos problemas. Y las dos primeras opciones ya están habilitadas en las nuevas versiones de git.
nPcomp
@sonyvizio ¿Qué tipo de problemas?
shoelzer
102

¿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='$'
Chris Dolan
fuente
11
El problema es con $(__git_ps1)... eliminar esto hace que todo sea súper rápido
Hendy Irawan
10
Para los no iniciados entre nosotros, ¿qué hace exactamente este comando? Dices que es "temporal", ¿cómo revertimos el comando?
Inmortal Blue
55
También reparó mis problemas de rendimiento. Para arreglarlo permanentemente, edite C:\Program Files (x86\Git\etc\profiley comente el if-then-else donde __git_ps1se agrega PS1.
Tom
66
En la versión actual 2.18.0 no puedo encontrar el comando __git_ps1 en / etc / profile. ¿Se ha mudado a otro lugar?
keinabel
8
Parece haberse movido a C: \ Archivos de programa \ Git \ etc \ profile.d \ git-prompt.sh. Comenté __git_ps1 en ese archivo y fue mucho más rápido (pero perdí la información de la rama en el aviso)
Miyagi
85

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.

Rob Johnson
fuente
66
Tuve el mismo problema Me cambié HOME="$(cd "$HOME" ; pwd)"a HOME="$(cd "$USERPROFILE" ; pwd)", y ahora todo es increíblemente rápido. Gracias por el consejo.
Jon Sagara
2
Tuve éxito usando una variación de esto: en el perfil, fuerce $ HOME a $ USERPROFILE, eliminando la referencia $ HOMEDRIVE. También en las propiedades del acceso directo de Git Bash, establezca "Iniciar en" en% USERPROFILE%
Aidan Ryan
11
Esto solucionó mi problema en su mayor parte, pero con Git al menos a partir de 2.7.2, encontré esa exportación en /etc/profile.d/env.sh en lugar de directamente en el archivo / etc / profile.
Jared Siirila
15
Muchas gracias, el mismo problema para mí, sin embargo, lo solucioné creando una variable de entorno (usuario) llamada HOME, apuntando a mi directorio de inicio deseado. Si $ HOME no está presente, aparentemente git bash se configurará por defecto en% USERPROFILE%. Después de esto, git bash es increíblemente rápido.
JHH
66
La única opción que funcionó fue la que @JHH describió en los comentarios. Agregue una variable de entorno de usuario de Windows llamada INICIO y defina su directorio de inicio deseado. (Panel de control -> Sistema -> Configuración avanzada del sistema -> Variables de entorno)
RenRen
45

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%
MichaelK
fuente
44
Esto funcionó. Para todos los que tienen el problema de la red, esta es la solución real. No tiene que editar ningún archivo de configuración, solo haga que HOME apunte donde debería.
Carlos Calla
1
Definir Env User Var HOME como% USERPROFILE% no funcionó. Definí SYSTEM VAR: HOME = C: \ Users \ myUserName
colin_froggatt
¡Trabajó para mi! Gracias. Hice algo como @colin_froggatt pero en cambio en las variables de entorno de usuario, configurando HOME = C: \ Users \ myUserName
Ð ..
22

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 .

Wilbert
fuente
Gran respuesta. Sin embargo, he decidido redefinir '__git_ps1 ()' en mi ~ / .bashrc e imprimir una cadena vacía. Acelera todos los comandos de Bash.
ajukraine
Soy un principiante de git, me gustaría saber cuál es la diferencia entre este fast_git_ps1 y el original bastante complicado __git_ps1. Tengo la idea de que esto funcionará para la mayoría de los casos "normales", pero ¿qué es normal y dónde fallará?
sundar - Restablece a Monica el
No estoy al tanto de los casos en que fallará. Utilicé el __git_ps1 antes, pero noté los problemas de rendimiento, así que intenté hacer que git hiciera menos trabajo para extraer la información mostrada.
Wilbert
2
El original __git_ps1incluye información de estado, no solo el nombre de la sucursal. Por ejemplo, si está en un estado de cabeza separada, en el directorio git, en un repositorio desnudo, en el medio de la selección de cerezas, rebase o fusión ... Esto será más rápido, pero puede haber ocasiones en las que fallaría Esta información adicional, especialmente como un principiante de Git.
Drew Noakes
22

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 .

Jeff Lamb
fuente
10
Esto solo pone de manifiesto, una vez más, a los idiotas y las meandrosas soluciones de Microsoft, a los problemas resueltos en Unix de una manera simple y elegante en 1968. Cuánto esfuerzo de producción, tiempo y dinero ha sido desperdiciado por la hinchazón de Microsoft y la falta de refactorización / flexibilidad / audacia en todo el mundo?
v.oddou
20
Recuerdo haber usado git en 68, fue glorioso.
Charlie Brown
2
Jaja un año antes de que Linus viniera @CharlieBrown
cchamberlain
1
habilitado por defecto en git 2.1 stackoverflow.com/a/24045966/4854931
Alex78191
18

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.

Géminis14
fuente
3
Reinstalar sin reiniciar no funcionó, desinstalar-reiniciar-instalar funcionó. ¡Gracias! Sin embargo, sería bueno saber por qué y cómo bash se volvió tan lento.
Gauthier
Reinstalar con reiniciar en el medio no me hizo ninguna diferencia.
RyanW
@RyanW Me temo que no puedo ayudar más allá de la solución anterior que me funcionó, pero dado que este problema aún no parece estar solucionado permanentemente, es posible que desee ponerse en contacto con los mantenedores de msysgit y ver si pueden resolver fuera la causa de este problema.
Gemini14
3
¿Qué archivos de configuración de bash borraste exactamente?
Scott
3
Esta no es la solución a la respuesta. Cuando desinstaló y reinstaló algún archivo de configuración que podría haber cambiado, esos cambios son la respuesta. Si solo dice que reinstalar es la solución, está mal. Otras personas pueden desinstalar y reinstalar y los archivos de configuración pueden ser iguales y es por eso que no funcionará para todos.
Carlos Calla
10

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

Chris Pawlukowsky
fuente
10
La pregunta habla sobre git bash.
manojlds
2
Puede ejecutar git bash como administrador; lo que puede indicar un problema UAC
krosenvold
3
Wow, gran mejora de velocidad ejecutando git bash como administrador
Evil E
No estoy seguro de por qué esta respuesta tiene solo 6 votos. Creo que esta respuesta resolvió el problema por completo. Hay una gran mejora de velocidad.
vinoth10
2
@ vinoth10 Bueno, está el problema con, ya sabes, correr como administrador. Lo cual por muchas razones es una mala idea, y para muchos casos de uso corporativo no es una opción en absoluto. Resolver un problema de rendimiento elevando al usuario es una solución horrible.
JHH
6

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).

sinelaw
fuente
También puede usar la --shortopción para no imprimirrefs/heads/
friederbluemle
@friederbluemle, ¿qué versión de git estás usando? El mío (1.7.9) no ofrece --shortel symbolic-refcomando.
sinelaw
Actualizado para no imprimir errores cuando está fuera de cualquier repositorio de git, y para trabajar con HEADs separados
sinelaw
Estoy usando 1.8.4 (msysgit)
friederbluemle
6

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

Olivier
fuente
5

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.

Nkosi Dean
fuente
4

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.

codehearts
fuente
2

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.

Eugene Pakhomov
fuente
2

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:

frolowr @ RWAMW36650 / c / projects / elm-math-kids (maestro) $

rofrol
fuente
no lo hizo más rápido
keinabel
@keinabel En este momento miraría core.commitGraph=truedesde blogs.msdn.microsoft.com/devops/2018/06/25/… y otros desde blogs.msdn.microsoft.com/devops/tag/git
rofrol
2

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.

Filete Binario
fuente
1
Apagar el UAC parece resolver la parte "grande" del problema para nosotros (retraso de varios segundos). El hack de ps1 hizo el resto.
krosenvold
Lo mismo estoy en SSD, 32 GB de RAM y quad core i7 y ninguna de las otras respuestas ayudó, deshabilitó UAC, reiniciar y los comandos git son INSTANTÁNEOS
phil_lgr
2

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\*.

Mastergalen
fuente
Quiero confirmar estos consejos. Excluir git de Avast realmente hace las cosas más rápido. Veo el estado de git sin esperar más. Victoria 7 x64
fajarhac
Los antivirus solo interfieren.
Alex78191
1
Gracias, ¡definitivamente fue una victoria rápida! Inhabilitado avast durante 10 minutos, notó un cambio instantáneo en el rendimiento de git (es decir, regreso a los tiempos de ejecución normales).
Marcello Romani
Esta solución funcionó para mí. McAfee + Windows 10 Ent.
FractalSpace
1

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

Jorge
fuente
llser un alias para log? Parece extraño que haya solicitudes de DNS para eso.
Michael - ¿Dónde está Clay Shirky?
1
lles un alias para ls -l. Y todavía es extraño activar una solicitud de DNS de todos modos ... Mientras tanto, todavía estoy esperando que este problema vuelva a aparecer para agregar más detalles en la respuesta.
George
1

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.

mahacoder
fuente
Creo que esta respuesta debería tener más votos. Vine aquí para publicar esta misma recomendación, pero vi que ya me ganaste jajaja.
Jon
0

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.

Koshmaar
fuente
¿Entonces su problema fue causado por un guión que había escrito? Tal vez ese script no sea la causa, para otros usuarios que buscan el mismo problema ...
Jolta
Eche un vistazo a la pregunta de OP: mencionó muchas cosas que había verificado, y aún así no fue así. Lo mismo fue conmigo. Así que aquí agregué otra cosa para verificar cuando nada ayuda. Y no es este script específico lo que he escrito que es importante, sino un concepto: mira tu PS1.
Koshmaar
0

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.

mrcl
fuente
0

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 .

Bergmeister
fuente
Eso ayuda stash, pero la tuya es la primera publicación que menciona stashespecíficamente. ¿Afecta a otras operaciones de Git?
Michael - ¿Dónde está Clay Shirky?
Por lo que yo entiendo, no. Hay 2 características experimentales en la vista previa que permiten tener stashy / o rebaseusar un ejecutable nativo para un mejor rendimiento, pero con cualquier cosa en la vista previa siempre hay una pequeña posibilidad de que pueda haber un pequeño efecto secundario.
bergmeister
1
PD: Esta característica se salió de la vista previa en v 2.19.1, por lo tanto, ya no tienes la opción para ello
bergmeister