Git Bash est extrêmement lent sur Windows 7 x64

J'ai utilisé Git sur Windows et Ubuntu pendant le développement d'un petit projet, alternant fréquemment entre les deux. Le problème est que Git Bash devient constamment lent.

Quand je dis lent, je veux dire que l'exécution cdprend de 8 à 25 secondes, l'exécution des gitcommandes de 5 à 20 secondes, etls peuvent parfois prendre jusqu'à 30 secondes. Inutile de dire que ce n'est pas amusant, pour ne pas mentionner improductif. Je sais que Git est plus lent sur Windows, mais c'est ridicule.

La seule solution qui a fonctionné - temporairement - pour moi a été de désactiver ma connexion réseau (comme suggéré dans cette réponse ), de démarrer Git Bash, puis de se reconnecter. Parfois, il continue de fonctionner rapidement pendant des jours après cela, mais les performances finissent toujours par se dégrader. J'ai parcouru le groupe de discussion msysgit, Stack Overflow, la liste des problèmes msysgit, etc. pendant des semaines, mais je n'ai pas été en mesure de trouver des solutions qui fonctionnent.

Jusqu'à présent, j'ai essayé:

• Ajout de dossiers Git et de projet à la liste d'exclusion de l'antivirus
• Désactiver complètement mon antivirus (Kaspersky IS 2011)
• Vérification que Outlook n'est pas en cours d'exécution (Outlook 2007)
• Fermeture de toutes les autres applications
• Exécuter Git Bash en tant qu'administrateur
• Désactiver la connexion réseau, démarrer Git Bash et garder la connexion désactivée
• Désactiver la connexion réseau, démarrer Git Bash, réactiver la connexion (ne fonctionne qu'occasionnellement)
• Fonctionnement git gc
• Et des combinaisons de ce qui précède

J'ai lu que quelques personnes avaient réussi à désactiver la complétion de Bash, mais dans l'idéal, j'aimerais que cela reste actif. La version de msysgit est 1.7.3.1-preview20101002 et le système d'exploitation est Windows 7 x64. L'exécution des mêmes choses sur Linux est, comme on pouvait s'y attendre, rapide comme l'éclair. J'utiliserais Linux exclusivement, mais je dois aussi exécuter des trucs sous Windows (certaines applications, tests, etc.).

Quelqu'un a-t-il rencontré un problème similaire? Si oui, quel était le problème sous-jacent et quelle était la solution (le cas échéant)?

Cela va au-delà des référentiels Git, mais juste pour référence, les référentiels avec lesquels j'ai utilisé Git étaient assez petits: ~ 4 à 50 fichiers maximum.

Vous pouvez accélérer considérablement Git sur Windows en exécutant trois commandes pour définir certaines options de configuration:

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

Remarques:

• core.preloadindex effectue des opérations sur le système de fichiers en parallèle pour masquer la latence (mise à jour: activée par défaut dans Git 2.1)

• core.fscache corrige les problèmes UAC afin que vous n'ayez pas besoin d'exécuter Git en tant qu'administrateur (mise à jour: activée par défaut dans Git pour Windows 2.8)

• gc.auto minimise le nombre de fichiers en .git /

Des informations Git s'affichent-elles dans votre invite Bash? Si c'est le cas, vous faites peut-être par inadvertance beaucoup trop de travail sur chaque commande. Pour tester cette théorie, essayez la modification temporaire suivante dans Bash:

export PS1='$'

Mon répertoire personnel Windows est sur le réseau, et je soupçonnais que les commandes Git Bash y étaient en premier. Effectivement, quand j'ai regardé $PATH, il a énuméré en /h/binpremier, où se /htrouve un partage sur un serveur de fichiers Windows, même s'il /h/binn'existe pas.
J'ai édité /etc/profileet commenté la commande d'exportation qui la place en premier dans $PATH:

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

Cela a rendu mes commandes plus rapides, probablement parce que Git Bash ne recherche plus les exécutables sur le réseau. Mon /etc/profileétait c:\Program Files (x86)\Git\etc\profile.

J'ai trouvé que le lecteur réseau était le problème de performances. HOMEpointait vers un partage réseau lent. Je ne pouvais pas passer outre HOMEDRIVEmais ce n'est pas un problème d'après ce que j'ai vu.

Définissez la variable d'environnement en cliquant avec le bouton droit sur votre ordinateur sur le bureau -> propriétés -> Paramètres système avancés -> Variables d'environnement Ajouter à la section Variables utilisateur

HOME=%USERPROFILE%

Dans une extension de la réponse de Chris Dolan, j'ai utilisé le PS1paramètre alternatif suivant . Ajoutez simplement le fragment de code à votre ~ / .profile (sous 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\]
$ '

Cela conserve l'avantage d'un shell coloré et l'affichage du nom de la branche actuelle (si dans un référentiel Git), mais c'est beaucoup plus rapide sur ma machine, de ~ 0,75 s à 0,1 s.

Ceci est basé sur cet article de blog .

Bien que votre problème puisse être lié au réseau, j'ai personnellement git statusmultiplié par dix mes appels locaux (7+ secondes jusqu'à 700 ms) en faisant deux modifications. Il s'agit d'un référentiel de 700 Mo avec 21 000 fichiers et un nombre excessif de gros fichiers binaires.

L'une consiste à activer les précharges d'index parallèles. À partir d'une invite de commande:

git config core.preloadindex true
Cela est passé time git statusde 7 secondes à 2,5 secondes.

Mise à jour!

Ce qui suit n'est plus nécessaire. Un correctif a corrigé ce problème depuis mysysgit 1.9.4
https://github.com/msysgit/git/commit/64d63240762df22e92b287b145d75a0d68a66988
Cependant, vous devez activer le correctif en tapant
git config core.fscache true

J'ai également désactivé l'UAC et le pilote "luafv" (redémarrage requis). Cela désactive un pilote dans Windows Vista, 7 et 8 qui redirige les programmes essayant d'écrire vers des emplacements système et redirige à la place ces accès vers un répertoire utilisateur.

Pour voir une discussion sur la façon dont cela affecte les performances de Git, lisez ici: https://code.google.com/p/msysgit/issues/detail?id=320

Pour désactiver ce pilote, dans regedit, remplacez la touche "start" HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/luafvpar 4 pour désactiver le pilote. Ensuite, placez l'UAC à son paramètre le plus bas, "ne jamais notifier".

Si la désactivation de ce pilote vous rend méfiant (il devrait), une alternative s'exécute sur un lecteur (ou une partition) différent de votre partition système. Apparemment, le pilote ne s'exécute que sur l'accès aux fichiers sur la partition système. J'ai un deuxième disque dur et je vois des résultats identiques lorsqu'il est exécuté avec cette modification de registre sur mon lecteur C comme je le fais sans lui sur le lecteur D.

Ce changement prend time git statusde 2,5 secondes à 0,7 secondes.

Vous pouvez également suivre https://github.com/msysgit/git/pull/94 et https://github.com/git/git/commit/d637d1b9a8fb765a8542e69bd2e04b3e229f663b pour vérifier les travaux supplémentaires en cours pour les problèmes de vitesse dans Windows .

Il semble que désinstaller complètement Git, redémarrer (le remède classique de Windows) et réinstaller Git était le remède. J'ai également effacé tous les fichiers de configuration bash qui étaient restés (ils ont été créés manuellement). Tout est à nouveau rapide.

Si pour une raison quelconque, la réinstallation n'est pas possible (ou souhaitable), j'essaierais certainement de changer la variable PS1 référencée dans la réponse de Chris Dolan ; cela a entraîné des accélérations importantes dans certaines opérations.

J'ai résolu mon lent problème Git sur Windows 7 x64 en démarrant cmd.exe avec "Exécuter en tant qu'administrateur".

J'ai vu une amélioration décente en définissant core.preloadindex sur true comme recommandé ici .

Comme indiqué dans les réponses de Chris Dolan et Wilbert, la PS1 vous ralentit .

Plutôt que de désactiver complètement (comme suggéré par Dolan) ou d'utiliser le script proposé par Wilbert, j'utilise une "PS1 stupide" qui est beaucoup plus rapide.

Il utilise (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\]# '

Sur mon Cygwin, c'est plus rapide que la réponse "fast_Git_PS1" de Wilbert - 200 ms contre 400 ms, donc cela réduit un peu votre lenteur rapide.

Ce n'est pas aussi sophistiqué que __git_ps1 - par exemple, cela ne change pas l'invite lorsque vous cd dans le répertoire .git, etc. mais pour une utilisation quotidienne normale, c'est assez bon et rapide.

Cela a été testé sur Git 1.7.9 (Cygwin, mais cela devrait fonctionner sur n'importe quelle plate-forme).

Vous pouvez également obtenir une amélioration des performances très faible en modifiant la configuration Git suivante:

git config --global status.submoduleSummary false

Lors de l'exécution du simple git status commande sur Windows 7 x64, mon ordinateur a pris plus de 30 secondes. Une fois cette option définie, la commande est immédiate.

L'activation du traçage de Git comme expliqué dans la page suivante m'a aidé à trouver l'origine du problème, qui peut différer dans votre installation: https://github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is-soso- lent

J'avais le même problème, à la fois dans Git Bash et Git GUI. Les deux programmes fonctionnaient bien, mais ils ont ensuite ralenti au hasard pour une analyse, et je n'ai pas pu comprendre pourquoi.

En fait, c'était Avast. Avast a causé des choses étranges à divers programmes (y compris les programmes que j'écris), donc je l'ai désactivé pendant une seconde, et bien sûr, Bash fonctionne maintenant aussi vite qu'il le fait sur Linux. Je viens d'ajouter le dossier des fichiers du programme Git (C:\Program Files\Git ) à la liste d'exclusion Avast, et maintenant il fonctionne aussi vite que sous Linux.

Et oui, je me rends compte que le logiciel antivirus n'était pas le problème dans le message d'origine, mais je vais juste le mettre ici au cas où il serait utile à quelqu'un.

En plus de ces autres réponses, j'ai accéléré des projets avec plusieurs sous-modules en utilisant la récupération de sous-modules parallèle (depuis Git 2.8 début 2016).

Cela peut être fait avec git fetch --recurse-submodules -j8et défini avec git config --global submodule.fetchJobs 8, ou quel que soit le nombre de cœurs que vous avez / souhaitez utiliser.

Si vous utilisez Git à partir de cmd, essayez de l'exécuter à partir de Git Bash. Dans cmd, git.exe est en fait un wrapper qui configure l'environnement correct chaque fois que vous le démarrez, et ne lance ensuite que le vrai git.exe. Cela peut prendre jusqu'à deux fois plus de temps que nécessaire pour faire ce que vous voulez. Et Git Bash ne configure l'environnement qu'au démarrage.

Seule la désactivation de AMD Radeon Graphics (ou Intel Graphics) dans le Gestionnaire de périphériques m'a aidé.

J'ai trouvé la réponse ici: /superuser/1160349/git-is-extremely-slow-on-windows# =

Réponses combinées:

1. Wilbert - quelles informations inclure dans PS1
2. sinelaw's - (<branch_name>)ou(<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}\] $ '

Résultat:

J'ai rencontré le même problème pendant l'exécution de Git pour Windows (msysgit) sur Windows 7 x64 en tant que compte d'utilisateur limité pendant un certain temps.

D'après ce que j'ai lu ici et ailleurs, le thème commun semble être le manque de privilèges administratifs et / ou UAC. Étant donné que l'UAC est désactivé sur mon système, l'explication selon laquelle il essaie d'écrire / supprimer quelque chose dans le répertoire des fichiers programme a le plus de sens pour moi.

Dans tous les cas, j'ai résolu mon problème en installant la version portable de Git 1.8 avec zipinstaller. Notez que j'ai dû décompresser le fichier de distribution .7z et le reconditionner en tant que fichier ZIP pour que zipinstaller fonctionne. J'ai également dû ajouter manuellement ce répertoire à mon chemin système.

La performance est maintenant bien. Même s'il est installé dans le Program Files (x86)répertoire, pour lequel je n'ai pas d'autorisations en tant qu'utilisateur limité, il ne semble pas souffrir du même problème.

J'attribue cela soit au fait que la version portable est un peu plus conservatrice dans les cas où elle écrit / supprime des fichiers, ce qui est probablement le cas, soit à la mise à niveau de 1.7 à 1.8. Je ne vais pas essayer de déterminer laquelle est la raison, il suffit de dire que cela fonctionne beaucoup mieux maintenant, y compris Bash.

Dans mon cas, c'était en fait un antivirus Avast conduisant à Git Bash et même PowerShell devenant vraiment lent.

J'ai d'abord essayé de désactiver Avast pendant 10 minutes pour voir si cela améliorait la vitesse et ce fut le cas. Ensuite, j'ai ajouté l'intégralité du répertoire d'installation de Git Bash en tant qu'exception dans Avast, pour la lecture, l'écriture et l'exécution. Dans mon cas, c'était C:\Program Files\Git\*.

Rien de ce qui précède n'a pu m'aider. Dans mon scénario, le problème se présentait comme ceci:

• Tout ll commande était lente (prenait environ 3 secondes à exécuter)
• Toute llcommande suivante a été exécutée instantanément, mais uniquement dans les 45 secondes suivant la commande ls précédente .

En ce qui concerne le débogage avec Process Monitor il a été constaté qu'avant chaque commande, il y avait une demande DNS.

Donc, dès que j'ai désactivé mon pare-feu (Comodo dans mon cas) et que j'ai laissé la commande exécuter, le problème a disparu. Et il ne revient pas lorsque le pare-feu a été réactivé. À la première occasion, je mettrai à jour cette réponse avec plus de détails sur le processus qui effectuait une demande de blocage DNS et quelle était la cible.

BR, G

Dans mon cas, le raccourci Git Bash a été défini sur Start in:%HOMEDRIVE%%HOMEPATH%(vous pouvez le vérifier en cliquant avec le bouton droit sur Git Bash et en sélectionnant les propriétés). C'était le lecteur réseau.

La solution est de le faire remarquer %HOME%. Si vous ne l'avez pas, vous pouvez le configurer dans les variables d'environnement et maintenant Git Bash devrait être rapide comme l'éclair.

J'ai également eu un problème avec la lenteur de git PS1, même si pendant longtemps j'ai pensé que c'était un problème de taille de base de données (grand référentiel) et que j'essayais diverses git gcastuces, et que je cherchais d'autres raisons, tout comme vous. Cependant, dans mon cas, le problème était cette ligne:

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
}

La procédure git statuspour la ligne d'état de chaque ligne de commande était lente. Aie. C'est quelque chose que j'ai écrit à la main. J'ai vu que c'était un problème quand j'ai essayé le

export PS1='$'

comme mentionné dans une réponse ici. La ligne de commande était rapide comme l'éclair.

Maintenant j'utilise ceci:

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

De la ligne PS1 Postflow Overflow avec la branche et les couleurs actuelles de git et cela fonctionne très bien. Encore une fois, disposez d'une ligne de commande Git rapide.

Un de mes collègues a eu des problèmes avec Git sur Windows (7) git status checkoutet a addété rapide, mais a git commitpris des siècles.

Nous essayons toujours de trouver la cause première de cela, mais le clonage du référentiel dans un nouveau dossier a résolu son problème.

Comme beaucoup l'ont dit, cela est dû au fait qu'il stashs'agit d'un script shell sur Windows, mais depuis Git 2.18.0, le programme d'installation de Windows a une option pour une fonctionnalité expérimentale d'une version intégrée beaucoup plus rapide (~ 90%) de stash - https: / /github.com/git-for-windows/build-extra/pull/203 .