Git Bash est extrêmement lent sur Windows 7 x64


436

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.


1
Pour ne pas vous décourager mais Cygwin est très lent sur x64, il vaut mieux l'essayer sur Windows XP 32bit.
ismail


5
Sur le même système, cela n'a pas été lent il y a six mois. Ils ont dû changer quelque chose ...
Tomáš Zato - Rétablir Monica

2
Sur pratiquement toutes les machines ici: Kaspersky AV ralentit massivement git et "désactiver" Kaspersky est cassé, avp.exe fonctionne toujours après l'avoir complètement quitté. La réinstallation complète de kaspersky résout généralement ce dernier problème.
peterchen

Réponses:


409

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 /


Cela ne m'a pas aidé, mais a aidé l'exportation PS1 = '$' mentionnée ci-dessous. Je sais donc que le problème, c'est la ligne terminale.
Koshmaar

67
Paramètres complètement inutiles en 2017 (git 2.12) car tout cela est activé par défaut. Mais le git fonctionne toujours lentement comme une merde.
ieXcept

2
Fonctionne également très bien sur Windows 10. Bravo et merci pour ce @shoelzer!
Joe

1
Limiter les fichiers à 256 peut entraîner des problèmes. Et les deux premières options déjà activées sur les nouvelles versions de git.
nPcomp

@sonyvizio Quel genre de problèmes?
shoelzer

102

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='$'

11
Le problème est avec $(__git_ps1)... la suppression de cela rend tout super rapide
Hendy Irawan

10
Pour les non initiés parmi nous, que fait exactement cette commande? Vous dites que c'est "temporaire", comment revenons-nous à la commande?
Immortal Blue

5
Correction également de mes problèmes de performances. Pour corriger définitivement, modifiez C:\Program Files (x86\Git\etc\profileet commentez le si-alors-autre où __git_ps1est ajouté PS1.
Tom

6
Dans la version actuelle 2.18.0, je ne trouve pas la commande __git_ps1 dans / etc / profile. A-t-il déménagé ailleurs?
keinabel

8
Il semble avoir migré vers C: \ Program Files \ Git \ etc \ profile.d \ git-prompt.sh. J'ai commenté __git_ps1 dans ce fichier et il est allé beaucoup plus vite (mais j'ai perdu les informations de branche dans l'invite)
Miyagi

85

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.


6
J'ai eu le même problème. J'ai changé HOME="$(cd "$HOME" ; pwd)"pour HOME="$(cd "$USERPROFILE" ; pwd)", et maintenant tout est incroyablement rapide. Merci pour le conseil.
Jon Sagara

2
J'ai réussi à utiliser une variante de ceci: dans le profil, forcez $ HOME à $ USERPROFILE, supprimant la référence $ HOMEDRIVE. Également sur les propriétés du raccourci Git Bash, définissez "Start In" sur% USERPROFILE%
Aidan Ryan

11
Cela a résolu mon problème pour la plupart, mais avec Git au moins à partir de 2.7.2, j'ai trouvé que l'exportation dans /etc/profile.d/env.sh au lieu de directement dans le fichier / etc / profile.
Jared Siirila

15
Merci beaucoup, même problème pour moi, mais je l'ai résolu en créant une variable d'environnement (utilisateur) appelée HOME, pointant vers le répertoire personnel de mon choix. Si $ HOME n'est pas présent, apparemment git bash sera par défaut à% USERPROFILE%. Après cela, git bash est rapide comme l'éclair.
JHH

6
La seule option qui a fonctionné était celle de @JHH décrite dans les commentaires. Ajoutez une variable d'environnement utilisateur Windows appelée HOME et définissez le répertoire de base de votre choix. (Panneau de configuration -> Système -> Paramètres système avancés -> Variables d'environnement)
RenRen

45

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%

4
Cela a fonctionné. Pour tous ceux qui ont un problème de réseau, c'est la vraie solution. Vous n'avez pas besoin de modifier un fichier de configuration, faites simplement HOME où il devrait.
Carlos Calla

1
La définition de l'utilisateur utilisateur Var HOME comme% USERPROFILE% n'a pas fonctionné. J'ai défini SYSTEM VAR: HOME = C: \ Users \ myUserName
colin_froggatt

A travaillé pour moi! Merci. J'ai fait quelque chose comme @colin_froggatt mais dans les variables d'environnement utilisateur à la place, en définissant HOME = C: \ Users \ myUserName
Ð ..

22

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 .


Très bonne réponse. Cependant, j'ai décidé de redéfinir '__git_ps1 ()' dans mon ~ / .bashrc, et d'imprimer simplement une chaîne vide. Il accélère toutes les commandes Bash.
ajukraine

Je suis un débutant git, j'aimerais savoir quelle est la différence entre ce fast_git_ps1 et le __git_ps1 assez compliqué d'origine. J'ai l'idée que cela fonctionnera pour la plupart des cas "normaux", mais qu'est-ce qui est normal et où cela échouera-t-il?
sundar

Je ne suis pas au courant des cas où cela échouera. J'ai déjà utilisé __git_ps1, mais j'ai remarqué des problèmes de performances, j'ai donc essayé de faire en sorte que git fasse moins de travail pour extraire les informations affichées.
Wilbert

2
L'original __git_ps1comprend des informations sur l'état, pas seulement le nom de la branche. Par exemple, si vous êtes dans un état de tête détaché, dans le répertoire git, dans un référentiel nu, au milieu de la cueillette des cerises ou du rebasage ou de la fusion ... Ce sera plus rapide, mais il peut y avoir des occasions où vous manqueriez cette info supplémentaire, surtout en tant que débutant Git.
Drew Noakes

22

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 .


10
cela ne fait que mettre à jour, encore une fois, des solutions idiotes et désobligeantes de Microsoft, à des problèmes résolus sous Unix de manière simple et élégante en 1968. audace dans le monde?
v.oddou

20
Je me souviens avoir utilisé git en 68, c'était magnifique.
Charlie Brown

2
Haha un an avant l'arrivée de Linus @CharlieBrown
cchamberlain

1
activé par défaut dans git 2.1 stackoverflow.com/a/24045966/4854931
Alex78191

18

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.


3
La réinstallation sans redémarrage n'a pas fonctionné, la désinstallation-redémarrage-installation a fonctionné. Merci! Ce serait bien de savoir pourquoi et comment bash est devenu si lent.
Gauthier

Réinstaller avec un redémarrage intermédiaire n'a fait aucune différence pour moi.
RyanW

@RyanW Je crains de ne pas pouvoir aider au-delà de la solution ci-dessus qui a fonctionné pour moi, mais comme ce problème ne semble pas encore être définitivement résolu, vous voudrez peut-être contacter les responsables de msysgit et voir s'ils peuvent comprendre la cause de ce problème.
Gemini14

3
Quels fichiers de configuration bash avez-vous effacés exactement?
Scott

3
Ce n'est pas la solution à la réponse. Lorsque vous avez désinstallé et réinstallé certains fichiers de configuration qui ont peut-être changé, ces changements sont la réponse. Si vous dites seulement que la réinstallation est la solution, c'est faux. D'autres personnes peuvent désinstaller et réinstaller et les fichiers de configuration peuvent être identiques et c'est pourquoi cela ne fonctionnera pas pour tout le monde.
Carlos Calla

10

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


10
La question parle de git bash.
Manojlds

2
Vous pouvez exécuter git bash en tant qu'administrateur; qui peut sembler indiquer un problème UAC
krosenvold

3
Wow, énorme amélioration de la vitesse en exécutant git bash en tant qu'administrateur
Evil E

Je ne sais pas pourquoi cette réponse n'a que 6 votes positifs. Je pense que cette réponse a résolu le problème complètement. Il y a une énorme amélioration de la vitesse.
vinoth10

2
@ vinoth10 Eh bien, il y a le problème avec, vous savez, l'exécution en tant qu'administrateur. Ce qui, pour de nombreuses raisons, est une mauvaise idée, et pour de nombreux cas d'utilisation en entreprise, ce n'est pas du tout une option. Résoudre un problème de performances en élevant l'utilisateur est une solution horrible.
JHH


6

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 utiliser l' --shortoption pour ne pas imprimerrefs/heads/
friederbluemle

@friederbluemle, quelle version de git utilisez-vous? Le mien (1.7.9) ne propose pas --shortla symbolic-refcommande.
sinelaw

Mis à jour pour ne pas imprimer d'erreurs en dehors de tout dépôt git et pour travailler pour les HEADs détachés
sinelaw

J'utilise 1.8.4 (msysgit)
friederbluemle

6

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


5

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.


4

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.


2

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.



2

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:

frolowr @ RWAMW36650 / c / projets / elm-math-kids (master) $


ne l'a pas fait plus vite
keinabel

@keinabel En ce moment , je regardais core.commitGraph=truede blogs.msdn.microsoft.com/devops/2018/06/25/... et d' autres de blogs.msdn.microsoft.com/devops/tag/git
rofrol

2

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.


1
La désactivation de l'UAC semble résoudre la "grande" partie du problème pour nous (délai de plusieurs secondes). Le hack ps1 a fait le reste.
krosenvold

De même, je suis sur SSD, 32 Go de RAM et quad core i7 et aucune des autres réponses n'a aidé, les commandes UAC, redémarrage et git désactivées sont INSTANTANÉES
phil_lgr

2

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


Je veux confirmer ces conseils. Exclure git d'Avast accélère vraiment les choses. Je vois le statut git sans attendre plus. Gagner 7 x64
fajarhac

Les antivirus n'interfèrent que.
Alex78191

1
Merci, c'était définitivement une victoire rapide! Avast désactivé pendant 10 minutes, a remarqué un changement instantané des performances de git (c'est-à-dire retour aux temps d'exécution normaux).
Marcello Romani

Cette solution a fonctionné pour moi. McAfee + Windows 10 Ent.
FractalSpace du

1

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


llêtre un alias pour log? Il semble étrange qu'il y ait des demandes DNS pour cela.
Michael - Où est Clay Shirky le

1
llest un alias pour ls -l. Et il est quand même étrange de déclencher une requête DNS de toute façon ... En attendant, j'attends toujours que ce problème apparaisse à nouveau pour ajouter plus de détails dans la réponse.
George

1

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.


Je pense que cette réponse devrait avoir plus de votes. Je suis venu ici pour poster cette même recommandation, mais je vous ai déjà vu me battre lol.
Jon

0

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.


Votre problème est donc dû à un script que vous avez écrit? Peut-être que ce script n'est probablement pas la cause, pour les autres utilisateurs qui recherchent le même problème ...
Jolta

Jetez un oeil à la question OP - il a mentionné beaucoup de choses qu'il avait vérifiées, et ce n'était toujours pas ça. La même chose était avec moi. Alors là, j'ai ajouté une autre chose à vérifier quand rien n'y fait. Et ce n'est pas ce script spécifique que j'ai écrit qui est important, mais un concept - regardez votre PS1.
Koshmaar

0

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.


0

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 .


Cela aide stash, mais le vôtre est le premier message mentionné stashspécifiquement. Cela affecte-t-il d'autres opérations Git?
Michael - Où est Clay Shirky

Pour autant que je comprends, non. Il y a 2 fonctionnalités expérimentales dans l'aperçu qui permettent d'avoir stashet / ou d' rebaseutiliser un exécutable natif pour de meilleures performances mais avec tout ce qui est en aperçu, il y a toujours une petite chance qu'il puisse y avoir un petit effet secondaire.
bergmeister

1
PS Cette fonctionnalité est sortie de l'aperçu dans la v 2.19.1, donc vous n'avez plus l'option pour elle
bergmeister
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.