Git Bash est extrêmement lent sous Windows 7 x64

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

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

Notes:

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

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

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

avez-vous des informations Git dans votre invite de Bash? Si c'est le cas, peut-être que vous faites par inadvertance beaucoup trop de travail sur chaque commande. Pour tester cette théorie essayer le changement temporaire suivant dans Bash:

export PS1='$'

mon répertoire Windows home est sur le réseau, et j'ai suspecté que les commandes de Git Bash y étaient en premier. Bien sûr, quand j'ai regardé $PATH, il a d'abord listé /h/bin, où /h est un partage sur un serveur de fichiers Windows, même si /h/bin n'existe pas. J'ai édité/etc / profile et commenté la commande export qui le place en premier dans $PATH:

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

cela a fait mes commandes courir beaucoup plus vite, probablement parce que Git Bash ne regarde plus à travers le réseau pour les exécutables. Mon profil était c:\Program Files (x86)\git\etc\profile.

j'ai trouvé le lecteur réseau était le problème de performance. HOME pointait du doigt un partage de réseau lent. Je ne pouvais pas remplacer HOMEDRIVE mais ce n'est pas un problème de ce que j'ai vu.

Réglez la variable d'environnement en cliquant avec le bouton droit de la souris votre ordinateur sur le bureau --> propriétés --> paramètres système Avancés --> Variables d'Environnement Ajouter à la section variables de L'utilisateur

HOME=%USERPROFILE%

dans un prolongement de la réponse de Chris Dolan, j'ai utilisé l'option suivante PS1 . Il suffit d'ajouter le fragment de code à votre ~/.profil (sur Windows 7: C:/Users/USERNAME/.profil.)

fast_git_ps1 ()
{
    printf -- "$(git branch 2>/dev/null | sed -ne '/^\* / s/^\* \(.*\)/ [] / p')"
}

PS1='\[3]0;$MSYSTEM:\w"151900920"7
3[32m\]\u@\h \[3[33m\w$(fast_git_ps1)3[0m\]
$ '

cela conserve l'avantage d'un shell coloré et l'affichage du nom actuel de la branche (si dans un dépôt Git), mais il est significativement plus rapide sur ma machine, de ~0.75 s à 0.1 s.

Ceci est basé sur ce blog .

bien que votre problème soit basé sur le réseau, j'ai personnellement accéléré mes appels locaux git status dix fois (7+ secondes jusqu'à 700 ms) en faisant deux modifications. Il s'agit d'un dépôt de 700 Mo avec 21 000 fichiers et un nombre excessif de gros fichiers binaires.

l'un permet des préchargements d'index parallèles. D'une invite de commande:

git config core.preloadindex true

ce qui change time git status de 7 secondes à 2,5 secondes.

mise à jour!

la mention suivante n'est plus nécessaire. Un patch a corrigé cela 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 aussi désactivé L'UAC et le conducteur" luafv " (redémarrage) requis.) Cela désactive un pilote dans Windows Vista, 7 et 8 qui redirige des programmes essayant d'écrire à des emplacements de système et redirige plutôt ces accès à un répertoire d'utilisateur.

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

pour désactiver ce pilote, dans regedit, changez la touche" start "à HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/luafv en 4 pour désactiver le pilote. Alors, mettez UAC à son niveau le plus bas, "never notify".

si la désactivation de ce pilote vous rend méfiant (il devrait), une alternative est en cours d'exécution sur un lecteur (ou une partition) différent de votre partition système. Apparemment, le pilote ne tourne que sur l'accès au fichier sur la partition système. J'ai un deuxième disque dur et voir des résultats identiques lorsqu'il est exécuté avec cette modification de Registre sur mon disque C comme je le fais sans Sur le disque D.

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

vous pourriez aussi vouloir suivre https://github.com/msysgit/git/pull/94 et https://github.com/git/git/commit/d637d1b9a8fb765a8542e69bd2e04b3e229f663b pour vérifier quels travaux supplémentaires sont en cours pour les problèmes de vitesse dans Windows.

j'ai résolu mon problème de Git lent 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 plaçant core.proloadindex à vrai comme recommandé ici .

comme L'indiquent les réponses de Chris Dolan et Wilbert, PS1 vous ralentit .

plutôt que de complètement désactiver (comme suggéré par Dolan) ou en utilisant le script offert par Wilbert, j'utilise un" muet PS1 " qui est beaucoup plus rapide.

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

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

sur mon Cygwin, c'est plus rapide que de Wilbert "fast_Git_PS1" réponse - 200 ms vs. 400 ms, donc il rase un un peu de votre lenteur immédiate.

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

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

j'avais le même problème, à la fois Git Bash et Git GUI. Les deux programmes fonctionnent bien, mais ils ont ralenti au hasard, et je n'ai pas compris pourquoi.

comme il s'avère, il était Avast. Avast a causé des choses étranges à divers programmes (y compris les programmes que j'écris), donc je l'ai désactivé une seconde, et bien sûr, Bash tourne maintenant aussi vite que sous Linux. Je viens d'ajouter le dossier git Program files ( C:\Program Files\Git ) à L'Avast liste d'exclusion, et maintenant il tourne aussi vite que sur Linux.

et oui, je réalise que le logiciel antivirus n'était pas le problème dans le post original, mais je vais juste mettre ceci ici au cas où il serait utile à quelqu'un.

vous pourriez également obtenir un gain de performance très subsquent en modifiant la configuration Git suivante:

git config --global status.submoduleSummary false

lors de L'exécution de la commande simple git status sur la fenêtre 7 x64, il a fallu plus de 30 secondes à mon ordinateur pour exécuter. Une fois cette option définie, la commande est immédiate.

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

si vous utilisez git de cmd, essayez de l'exécuter à partir de Git Bash. En cmd, git.exe est en fait un wrapper qui met en place le bon environnement à chaque fois que vous le démarrez, et ne lance alors 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 crée l'environnement seulement quand il commence.

réponses combinées:

1. Wilbert's - quelles informations inclure dans PS1
2. sinelaw - (<branch_name>) ou (<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
# 3 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")"

# /q/git-bash-is-extremely-slow-on-windows-7-x64-25911/" ($((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 en exécutant Git pour Windows (msysgit) sur Windows 7 x64 comme compte d'utilisateur limité depuis 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. Depuis UAC est éteint sur mon système, l'explication qu'il essaie d'écrire/supprimer quelque chose dans le répertoire de fichiers de 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. Note que j'ai eu pour décompresser le .7z fichier de distribution et le reconditionner en fichier ZIP Pour que zipinstaller fonctionne. J'ai aussi dû ajouter manuellement ce répertoire à mon chemin système.

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

Je l'attribue soit au fait que la version portable est un peu plus conservatrice là 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 cerner ce qui est la raison, autant dire qu'il fonctionne beaucoup mieux maintenant, y compris Bash.

dans mon cas, il était en fait Avast antivirus conduisant à Git Bash et même PowerShell devenant vraiment lent.

J'ai d'abord essayé de désactiver Avast pendant 10 minutes pour voir s'il améliorait la vitesse et il l'a fait. Par la suite, j'ai ajouté le répertoire d'installation complet de Git Bash en tant qu'exception dans Avast, pour lire, écrire et exécuter. Dans mon cas c'était C:\Program Files\Git\* .

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

cela peut être fait avec git fetch --recurse-submodules -j8 et défini avec git config --global submodule.fetchJobs 8 , ou combien de cœurs vous avez/voulez utiliser.

rien de ce qui précède n'a pu m'aider. Dans mon scénario, la question se montrait ainsi:

• toute commande ll était lente (l'exécution prenait environ 3 secondes)
• toute commande subséquente ll a été exécutée instantanément, mais seulement si dans les 45 secondes de la commande ls précédente .

quand il est venu à déboguer avec processus Moniteur il a été constaté qu'avant chaque commande il y avait une demande DNS.

dès que j'ai désactivé mon pare-feu (Comodo dans mon cas) et laissé la commande exécuter le problème est parti. Et il ne revient pas quand le pare-feu a été rallumé. Avec la première occasion, je vais mettre à jour cette réponse avec plus de détails sur ce que le processus faisait une demande DNS de blocage et ce qui était la cible.

BR, G

ne désactiver AMD Radeon Graphics (ou Intel Graphics) dans Device Manager m'a aidé.

j'ai trouvé la réponse ici: https://superuser.com/questions/1160349/git-is-extremely-slow-on-windows# =

j'ai aussi eu des problèmes avec la lenteur de la Git PS1, bien que pendant longtemps je pensais que c'était un problème de taille de base de données (grand dépôt) et j'ai essayé diverses astuces git gc , et 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
}

faire le git status pour chaque ligne de statut de ligne de commande était lent. Ouch. 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 colonne de débordement de la pile ligne PS1 avec la branche de courant git et les couleurs et il fonctionne très bien. Encore une fois avoir une ligne de commande rapide Git.

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

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

un de mes collègues a eu des problèmes avec Git sur les fenêtres (7) git status checkout et add étaient rapides, mais git commit a pris des âges.

nous essayons toujours de trouver la cause profonde de cela, mais cloner le dépôt dans un nouveau dossier a corrigé son problème.