Git Bash ist unter Windows 7 x64 extrem langsam

Ich habe Git sowohl unter Windows als auch unter Ubuntu während der Entwicklung eines kleinen Projekts verwendet und häufig zwischen den beiden hin und her gewechselt. Das Problem ist, dass Git Bash durchweg langsam wird.

Wenn ich langsam sage, meine ich, dass das Ausführen cdzwischen 8 und 25 Sekunden dauert, das Ausführen von gitBefehlen zwischen 5 und 20 Sekunden und lsmanchmal bis zu 30 Sekunden. Unnötig zu sagen, dass dies keinen Spaß macht, ganz zu schweigen von unproduktiv. Ich weiß, dass Git unter Windows langsamer ist, aber das ist lächerlich.

Die einzige Lösung, die - vorübergehend - für mich funktioniert hat, bestand darin, meine Netzwerkverbindung zu deaktivieren (wie in dieser Antwort vorgeschlagen ), Git Bash zu starten und dann die Verbindung wiederherzustellen. Manchmal läuft es danach tagelang schnell weiter, aber die Leistung verschlechtert sich immer irgendwann. Ich habe die msysgit-Diskussionsgruppe, den Stapelüberlauf, die msysgit-Problemliste usw. wochenlang ein- und ausgeschaltet, aber ich konnte keine funktionierenden Lösungen finden.

Bisher habe ich versucht:

• Hinzufügen von Git- und Projektordnern zur Ausschlussliste des Virenscanners
• Vollständiges Deaktivieren meines Virenscanners (Kaspersky IS 2011)
• Sicherstellen, dass Outlook nicht ausgeführt wird (Outlook 2007)
• Alle anderen Anwendungen herunterfahren
• Ausführen von Git Bash als Administrator
• Deaktivieren der Netzwerkverbindung, Starten von Git Bash und Deaktivieren der Verbindung
• Netzwerkverbindung deaktivieren, Git Bash starten, Verbindung wieder aktivieren (funktioniert nur gelegentlich)
• Laufen git gc
• Und Kombinationen der oben genannten

Ich habe gelesen, dass einige Leute erfolgreich die Bash-Fertigstellung deaktiviert haben, aber im Idealfall möchte ich das aktiv halten. Die Version von msysgit ist 1.7.3.1-Preview20101002 und das Betriebssystem ist Windows 7 x64. Dasselbe unter Linux auszuführen, ist vorhersehbar blitzschnell. Ich würde ausschließlich Linux verwenden, aber ich muss auch Dinge unter Windows ausführen (bestimmte Anwendungen, Tests usw.).

Hat jemand ein ähnliches Problem festgestellt? Wenn ja, was war das zugrunde liegende Problem und was war die Lösung (falls vorhanden)?

Dies geht über die Git-Repositorys hinaus, aber nur als Referenz: Die Repositorys, mit denen ich Git verwendet habe, waren ziemlich klein: maximal ~ 4-50 Dateien.

Sie können Git unter Windows erheblich beschleunigen, indem Sie drei Befehle ausführen, um einige Konfigurationsoptionen festzulegen:

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

Anmerkungen:

• core.preloadindex führt Dateisystemoperationen parallel aus, um die Latenz zu verbergen (Update: standardmäßig in Git 2.1 aktiviert)

• core.fscache behebt UAC-Probleme, sodass Sie Git nicht als Administrator ausführen müssen (Update: standardmäßig in Git für Windows 2.8 aktiviert)

• gc.auto minimiert die Anzahl der Dateien in .git /

Haben Sie Git-Informationen in Ihrer Bash-Eingabeaufforderung? Wenn ja, arbeiten Sie möglicherweise versehentlich viel zu viel an jedem Befehl. Um diese Theorie zu testen, versuchen Sie die folgende vorübergehende Änderung in Bash:

export PS1='$'

Mein Windows-Ausgangsverzeichnis befindet sich im Netzwerk, und ich vermutete, dass Git Bash-Befehle zuerst dort gesucht wurden. Sicher genug, als ich $PATHes mir ansah , wurde /h/binzuerst aufgelistet , wo /hsich eine Freigabe auf einem Windows-Dateiserver befindet, obwohl /h/binsie nicht vorhanden ist.
Ich habe /etc/profileden Exportbefehl bearbeitet und auskommentiert, der ihn an die erste Stelle setzt $PATH:

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

Dadurch wurden meine Befehle viel schneller ausgeführt, wahrscheinlich weil Git Bash nicht mehr im Netzwerk nach ausführbaren Dateien sucht. Mein /etc/profilewar c:\Program Files (x86)\Git\etc\profile.

Ich fand, dass das Netzlaufwerk das Leistungsproblem war. HOMEzeigte auf eine langsame Netzwerkfreigabe. Ich konnte nicht überschreiben, HOMEDRIVEaber das ist kein Problem von dem, was ich gesehen habe.

Legen Sie die Umgebungsvariable fest, indem Sie mit der rechten Maustaste auf Ihren Computer auf dem Desktop klicken -> Eigenschaften -> Erweiterte Systemeinstellungen -> Abschnitt Umgebungsvariablen Zu Benutzervariablen hinzufügen

HOME=%USERPROFILE%

In einer Erweiterung von Chris Dolans Antwort habe ich die folgende alternative PS1Einstellung verwendet. Fügen Sie einfach das Codefragment zu Ihrem ~ / .profile hinzu (unter 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\]
$ '

Dies behält den Vorteil einer farbigen Shell und der Anzeige des aktuellen Zweigstellennamens (wenn in einem Git-Repository), ist jedoch auf meinem Computer von ~ 0,75 s bis 0,1 s erheblich schneller.

Dies basiert auf diesem Blog-Beitrag .

Während Ihr Problem möglicherweise netzwerkbasiert ist, habe ich meine Ortsgespräche persönlich um git statusdas Zehnfache beschleunigt (7+ Sekunden auf 700 ms), indem ich zwei Änderungen vorgenommen habe. Dies befindet sich in einem 700-MB-Repository mit 21.000 Dateien und einer übermäßigen Anzahl großer Binärdateien.

Eine Möglichkeit besteht darin, parallele Indexvorladungen zu aktivieren. An einer Eingabeaufforderung:

git config core.preloadindex true
Dies änderte sich time git statusvon 7 Sekunden auf 2,5 Sekunden.

Aktualisieren!

Folgendes ist nicht mehr erforderlich. Ein Patch hat dies ab mysysgit 1.9.4 behoben.
Https://github.com/msysgit/git/commit/64d63240762df22e92b287b145d75a0d68a66988
Sie müssen das Update jedoch durch Eingabe aktivieren
git config core.fscache true

Ich habe auch die Benutzerkontensteuerung und den "luafv" -Treiber deaktiviert (Neustart erforderlich). Dadurch wird ein Treiber in Windows Vista, 7 und 8 deaktiviert, der Programme umleitet, die versuchen, an Systemspeicherorte zu schreiben, und stattdessen diese Zugriffe auf ein Benutzerverzeichnis umleitet.

Eine Diskussion darüber, wie sich dies auf die Git-Leistung auswirkt, finden Sie hier: https://code.google.com/p/msysgit/issues/detail?id=320

Um diesen Treiber zu deaktivieren, ändern Sie in regedit die Taste "Start" HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/luafvauf 4, um den Treiber zu deaktivieren. Stellen Sie dann die Benutzerkontensteuerung auf die niedrigste Einstellung "Niemals benachrichtigen".

Wenn Sie durch das Deaktivieren dieses Treibers vorsichtig werden (dies sollte der Fall sein), wird eine Alternative auf einem Laufwerk (oder einer Partition) ausgeführt, das sich von Ihrer Systempartition unterscheidet. Anscheinend läuft der Treiber nur beim Dateizugriff auf der Systempartition. Ich habe eine zweite Festplatte und sehe identische Ergebnisse, wenn ich diese Registrierungsänderung auf meinem C-Laufwerk ausführe, wie ich es ohne sie auf dem D-Laufwerk mache.

Diese Änderung dauert time git statusvon 2,5 Sekunden auf 0,7 Sekunden.

Sie können auch https://github.com/msysgit/git/pull/94 und https://github.com/git/git/commit/d637d1b9a8fb765a8542e69bd2e04b3e229f663b folgen , um herauszufinden, welche zusätzlichen Arbeiten für Geschwindigkeitsprobleme in Windows ausgeführt werden .

Es scheint, dass die vollständige Deinstallation von Git, der Neustart (die klassische Windows-Heilung) und die Neuinstallation von Git die Heilung waren. Ich habe auch alle verbleibenden Bash-Konfigurationsdateien gelöscht (sie wurden manuell erstellt). Alles ist wieder schnell.

Wenn eine Neuinstallation aus irgendeinem Grund nicht möglich (oder wünschenswert) ist, würde ich definitiv versuchen, die in Chris Dolans Antwort angegebene PS1-Variable zu ändern . Dies führte bei bestimmten Vorgängen zu erheblichen Beschleunigungen.

Ich habe mein langsames Git-Problem unter Windows 7 x64 gelöst, indem ich cmd.exe mit "Als Administrator ausführen" gestartet habe.

Ich habe eine anständige Verbesserung festgestellt, indem ich core.preloadindex auf true gesetzt habe, wie hier empfohlen .

Wie in den Antworten von Chris Dolan und Wilbert erwähnt, verlangsamt PS1 Sie .

Anstatt vollständig zu deaktivieren (wie von Dolan vorgeschlagen) oder das von Wilbert angebotene Skript zu verwenden, verwende ich eine "dumme PS1", die viel schneller ist.

Es verwendet (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\]# '

Auf meinem Cygwin ist dies schneller als Wilberts "fast_Git_PS1" -Antwort - 200 ms gegenüber 400 ms, sodass Sie ein wenig von Ihrer prompten Trägheit abschneiden.

Es ist nicht so ausgefeilt wie __git_ps1- zum Beispiel ändert es nicht die Eingabeaufforderung, wenn Sie in das .git-Verzeichnis usw. wechseln, aber für den normalen täglichen Gebrauch ist es gut genug und schnell.

Dies wurde auf Git 1.7.9 getestet (Cygwin, sollte aber auf jeder Plattform funktionieren).

Sie können auch eine sehr geringe Leistungssteigerung erzielen, indem Sie die folgende Git-Konfiguration ändern:

git config --global status.submoduleSummary false

Beim Ausführen des einfachen git statusBefehls unter Windows 7 x64 dauerte die Ausführung meines Computers mehr als 30 Sekunden. Nachdem diese Option definiert wurde, wird der Befehl sofort ausgeführt.

Durch Aktivieren von Gits eigener Ablaufverfolgung, wie auf der folgenden Seite erläutert, konnte ich den Ursprung des Problems ermitteln, das sich in Ihrer Installation unterscheiden kann: https://github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is-so- langsam

Ich hatte das gleiche Problem, sowohl in Git Bash als auch in Git GUI. Beide Programme liefen gut, aber dann wurden sie zufällig zu einem Crawl verlangsamt, und ich konnte nicht herausfinden, warum.

Wie sich herausstellte, war es Avast. Avast hat dazu geführt, dass bei verschiedenen Programmen (einschließlich der von mir geschriebenen Programme) seltsame Dinge passiert sind. Deshalb habe ich es für eine Sekunde deaktiviert, und Bash läuft jetzt genauso schnell wie unter Linux. Ich habe gerade den Ordner mit den Git-Programmdateien ( C:\Program Files\Git) zur Avast-Ausschlussliste hinzugefügt , und jetzt läuft er genauso schnell wie unter Linux.

Und ja, mir ist klar, dass die Antivirensoftware nicht das Problem im ursprünglichen Beitrag war, aber ich werde dies hier nur einfügen, falls es für jemanden nützlich ist.

Zusätzlich zu diesen anderen Antworten habe ich Projekte mit mehreren Submodulen durch paralleles Abrufen von Submodulen beschleunigt (seit Git 2.8 Anfang 2016).

Dies kann mit git fetch --recurse-submodules -j8und mit git config --global submodule.fetchJobs 8wie vielen Kernen Sie tun und einstellen möchten.

Wenn Sie Git von cmd verwenden, versuchen Sie, es von Git Bash aus auszuführen. In cmd ist git.exe tatsächlich ein Wrapper, der bei jedem Start die richtige Umgebung einrichtet und erst dann die echte git.exe startet. Es kann bis zu doppelt so lange dauern, bis Sie das tun, was Sie wollen. Und Git Bash richtet die Umgebung erst beim Start ein.

Nur das Deaktivieren von AMD Radeon Graphics (oder Intel Graphics) im Geräte-Manager hat mir geholfen.

Ich habe die Antwort hier gefunden: /superuser/1160349/git-is-extremely-slow-on-windows# =

Kombinierte Antworten:

1. Wilbert's - welche Infos in PS1 enthalten sein sollen
2. sinelaw's - (<branch_name>)oder(<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}\] $ '

Ergebnis:

Ich habe seit einiger Zeit das gleiche Problem beim Ausführen von Git für Windows (msysgit) unter Windows 7 x64 als eingeschränktes Benutzerkonto festgestellt.

Nach dem, was ich hier und an anderen Orten gelesen habe, scheint das gemeinsame Thema das Fehlen von Administratorrechten und / oder Benutzerkontensteuerung zu sein. Da die Benutzerkontensteuerung auf meinem System deaktiviert ist, ist die Erklärung, dass versucht wird, etwas in das Programmdateiverzeichnis zu schreiben / löschen, für mich am sinnvollsten.

In jedem Fall habe ich mein Problem durch die Installation der portablen Version von Git 1.8 mit zipinstaller behoben. Beachten Sie, dass ich die .7z-Verteilungsdatei entpacken und als ZIP-Datei neu packen musste, damit das zipinstaller funktioniert. Ich musste dieses Verzeichnis auch manuell zu meinem Systempfad hinzufügen.

Die Leistung ist jetzt in Ordnung. Obwohl es in der installiert istProgram Files (x86) Verzeichnis , für das ich als eingeschränkter Benutzer keine Berechtigungen habe, scheint es nicht unter demselben Problem zu leiden.

Ich schreibe dies entweder der Tatsache zu, dass die tragbare Version etwas konservativer ist, wenn sie Dateien schreibt / löscht, was wahrscheinlich der Fall ist, oder dem Upgrade von 1.7 auf 1.8. Ich werde nicht versuchen herauszufinden, welcher der Grund ist. Es reicht zu sagen, dass es jetzt viel besser funktioniert, einschließlich Bash.

In meinem Fall war es tatsächlich Avast Antivirus, was dazu führte, dass Git Bash und sogar PowerShell sehr langsam wurden.

Ich habe zuerst versucht, Avast für 10 Minuten zu deaktivieren, um festzustellen, ob es die Geschwindigkeit verbessert hat. Danach habe ich in Avast als Ausnahme das gesamte Git Bash-Installationsverzeichnis für Lesen, Schreiben und Ausführen hinzugefügt. In meinem Fall war das C:\Program Files\Git\*.

Nichts von alledem konnte mir helfen. In meinem Szenario zeigte sich das Problem folgendermaßen:

• Irgendein ll Befehl war langsam (die Ausführung dauerte ungefähr 3 Sekunden)
• Jeder nachfolgende llBefehl wurde sofort ausgeführt, jedoch nur innerhalb von 45 Sekunden nach dem vorherigen ls-Befehl .

Beim Debuggen mit Process Monitor wurde festgestellt, dass vor jedem Befehl eine DNS-Anforderung vorhanden war.

Sobald ich meine Firewall deaktiviert habe (in meinem Fall Comodo) und den Befehl ausführen ließ, ist das Problem behoben. Und es kehrt nicht zurück, wenn die Firewall wieder eingeschaltet wurde. Bei der frühesten Gelegenheit werde ich diese Antwort mit weiteren Details darüber aktualisieren, welcher Prozess eine blockierende DNS-Anfrage ausgeführt hat und was das Ziel war.

BR, G.

In meinem Fall wurde die Verknüpfung Git Bash auf gesetzt Start in:%HOMEDRIVE%%HOMEPATH%(Sie können dies überprüfen, indem Sie mit der rechten Maustaste auf Git Bash klicken und Eigenschaften auswählen). Dies war das Netzlaufwerk.

Die Lösung besteht darin, darauf hinzuweisen %HOME%. Wenn Sie es nicht haben, können Sie es in den Umgebungsvariablen einrichten und jetzt sollte Git Bash blitzschnell sein.

Ich hatte auch ein Problem mit der Langsamkeit von Git PS1, obwohl ich lange Zeit dachte, es sei ein Problem mit der Datenbankgröße (großes Repository) und verschiedene git gcTricks ausprobierte und nach anderen Gründen suchte, genau wie Sie. In meinem Fall war das Problem jedoch diese Zeile:

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
}

Das Ausführen der git statusStatuszeile für jede Befehlszeile war langsam. Autsch. Es war etwas, das ich von Hand geschrieben habe. Ich sah, dass das ein Problem war, als ich das versuchte

export PS1='$'

wie in einer Antwort hier erwähnt. Die Kommandozeile war blitzschnell.

Jetzt benutze ich das:

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

Aus der Stapelüberlauf-Post- PS1-Linie mit Git-Stromzweig und Farben und es funktioniert gut. Habe wieder eine schnelle Git Kommandozeile.

Ein Mitarbeiter von mir hatte Probleme mit Git unter Windows (7) git status checkoutund addwar schnell, aber es git commitdauerte ewig.

Wir versuchen immer noch, die Hauptursache dafür zu finden, aber das Klonen des Repositorys in einen neuen Ordner hat sein Problem behoben.

Wie viele sagten, liegt dies daran, stashdass es sich um ein Shell-Skript unter Windows handelt. Seit Git 2.18.0 bietet das Windows-Installationsprogramm jedoch die Option für eine experimentelle Funktion einer viel schnelleren (~ 90%) integrierten Version von stash - https: / /github.com/git-for-windows/build-extra/pull/203 .