Git Bash ist unter Windows 7 x64 extrem langsam

434

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.

Zwillinge14
quelle
1
Um Sie nicht zu entmutigen, aber Cygwin ist auf x64 sehr langsam. Versuchen Sie es besser unter Windows XP 32bit.
Ismail
2
mögliches Duplikat von Msysgit Bash ist in Windows 7
childno͡.de
5
Auf demselben System war es vor einem halben Jahr nicht langsam. Sie müssen etwas geändert haben ...
Tomáš Zato - Reinstate Monica
2
Auf praktisch allen Computern hier: Kaspersky AV verlangsamt git massiv und das "Deaktivieren" von Kaspersky ist fehlerhaft. Avp.exe wird nach dem vollständigen Beenden immer noch ausgeführt. Eine vollständige Neuinstallation von kaspersky behebt normalerweise das letztere Problem.
Peterchen
2
Siehe msysgits Wiki-Seite auf dieser: github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is-so-slow
Drew Noakes

Antworten:

410

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 /

Schuhmacher
quelle
Hat mir nicht geholfen, aber beim Exportieren von PS1 = '$' geholfen. Ich weiß also, dass das Problem die Terminalleitung ist.
Koshmaar
67
Völlig nutzlose Einstellungen im Jahr 2017 (Git 2.12), da all diese Dinge standardmäßig aktiviert sind. Aber der Idiot arbeitet immer noch langsam wie eine Scheiße.
ieXcept
2
Funktioniert auch unter Windows 10 hervorragend. Gut gemacht und danke für diesen @shoelzer!
Joe
1
Das Beschränken von Dateien auf 256 kann einige Probleme verursachen. Und die ersten beiden Optionen sind bereits in neuen Versionen von git aktiviert.
nPcomp
@sonyvizio Was für Probleme?
Shoelzer
102

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='$'
Chris Dolan
quelle
11
Das Problem ist mit $(__git_ps1)... das Entfernen macht alles superschnell
Hendy Irawan
10
Was genau macht dieser Befehl für die Uneingeweihten unter uns? Sie sagen, es ist "vorübergehend". Wie setzen wir den Befehl zurück?
Immortal Blue
5
Auch meine Leistungsprobleme wurden behoben. Um dies dauerhaft zu beheben, bearbeiten C:\Program Files (x86\Git\etc\profileund kommentieren Sie das Wenn-Dann-Sonst, wo __git_ps1hinzugefügt wird PS1.
Tom
6
In der aktuellen Version 2.18.0 kann ich den Befehl __git_ps1 nicht in / etc / profile finden. Ist es woanders hingezogen?
keinabel
8
Es scheint nach C: \ Programme \ Git \ etc \ profile.d \ git-prompt.sh verschoben worden zu sein. Ich habe __git_ps1 in dieser Datei auskommentiert und es ging viel schneller (aber verlor Zweiginformationen in der Eingabeaufforderung)
Miyagi
85

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.

Rob Johnson
quelle
6
Ich hatte das gleiche Problem. Ich wechselte HOME="$(cd "$HOME" ; pwd)"zu HOME="$(cd "$USERPROFILE" ; pwd)", und jetzt ist alles unglaublich schnell. Danke für den Tipp.
Jon Sagara
2
Ich habe eine Variation davon erfolgreich verwendet: Erzwingen Sie im Profil $ HOME auf $ USERPROFILE und entfernen Sie die $ HOMEDRIVE-Referenz. Setzen Sie auch auf den Eigenschaften der Git Bash-Verknüpfung "Start In" auf% USERPROFILE%
Aidan Ryan
11
Dies hat mein Problem größtenteils behoben, aber mit Git mindestens ab 2.7.2 fand ich diesen Export in /etc/profile.d/env.sh anstatt direkt in der Datei / etc / profile.
Jared Siirila
15
Vielen Dank, dasselbe Problem für mich, aber ich habe es behoben, indem ich eine (Benutzer-) Umgebungsvariable namens HOME erstellt habe, die auf mein gewünschtes Ausgangsverzeichnis verweist. Wenn $ HOME nicht vorhanden ist, wird anscheinend git bash standardmäßig auf% USERPROFILE% gesetzt. Danach ist Git Bash blitzschnell.
JHH
6
Die einzige Option, für die funktioniert hat, war die in den Kommentaren beschriebene @JHH. Fügen Sie eine Windows-Benutzerumgebungsvariable namens HOME hinzu und definieren Sie das gewünschte Basisverzeichnis. (Systemsteuerung -> System -> Erweiterte Systemeinstellungen -> Umgebungsvariablen)
RenRen
45

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%
MichaelK
quelle
4
Das hat funktioniert. Für alle, die das Netzwerkproblem haben, ist dies die echte Lösung. Sie müssen keine Konfigurationsdatei bearbeiten, sondern machen HOME zu einem Punkt, an dem es sein sollte.
Carlos Calla
1
Das Definieren von Env User Var HOME als% USERPROFILE% hat nicht funktioniert. Ich definierte SYSTEM VAR: HOME = C: \ Users \ myUserName
colin_froggatt
Hat für mich gearbeitet! Vielen Dank. Ich habe so etwas wie @colin_froggatt gemacht, aber stattdessen in Benutzerumgebungsvariablen HOME = C: \ Users \ myUserName
Ð ..
22

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 .

Wilbert
quelle
Gute Antwort. Ich habe mich jedoch entschlossen, '__git_ps1 ()' in meinem ~ / .bashrc neu zu definieren und einfach eine leere Zeichenfolge zu drucken. Es beschleunigt alle Bash-Befehle.
Ajukraine
Ich bin ein Git-Anfänger, ich würde gerne wissen, was der Unterschied zwischen diesem fast_git_ps1 und dem ursprünglichen ziemlich komplizierten __git_ps1 ist. Ich habe die Idee, dass dies in den meisten "normalen" Fällen funktioniert, aber was ist normal und wo wird dies fehlschlagen?
Sundar - Reinstate Monica
Mir sind keine Fälle bekannt, in denen dies fehlschlagen wird. Ich habe zuvor __git_ps1 verwendet, aber die Leistungsprobleme festgestellt. Deshalb habe ich versucht, git dazu zu bringen, weniger Arbeit zu leisten, um die angezeigten Informationen zu extrahieren.
Wilbert
2
Das Original __git_ps1enthält Statusinformationen, nicht nur den Filialnamen. Zum Beispiel, wenn Sie sich in einem Zustand mit losgelöstem Kopf befinden, im Git-Verzeichnis, in einem nackten Repo, mitten im Kirschpflücken oder Umbasieren oder Zusammenführen ... Dies wird schneller sein, aber es kann Gelegenheiten geben, in denen Sie es verpassen würden Diese zusätzlichen Informationen, insbesondere als Git-Anfänger.
Drew Noakes
22

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 .

Jeff Lamb
quelle
10
Dies zeigt nur noch einmal idiotische und sinnlose Microsoft-Lösungen für Probleme, die 1968 in Unix auf einfache und elegante Weise gelöst wurden. Wie viel Produktionsaufwand, Zeit und Geld wurden durch das Aufblähen von Microsoft und den Mangel an Refactoring / Flexibilität verschwendet. Kühnheit weltweit?
v.oddou
20
Ich erinnere mich, dass ich Git im Jahr 68 benutzt habe, es war herrlich.
Charlie Brown
2
Haha ein Jahr bevor Linus @CharlieBrown
cchamberlain
1
standardmäßig aktiviert in Git 2.1 Stackoverflow.com/a/24045966/4854931
Alex78191
18

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.

Zwillinge14
quelle
3
Neuinstallation ohne Neustart hat nicht funktioniert, Deinstallation-Neustart-Installation hat funktioniert. Vielen Dank! Es wäre schön zu wissen, warum und wie Bash so langsam wurde.
Gauthier
Eine Neuinstallation mit einem dazwischen liegenden Neustart machte für mich keinen Unterschied.
RyanW
@RyanW Ich fürchte, ich kann nicht anders als die oben beschriebene Lösung, die für mich funktioniert hat, aber da dieses Problem noch nicht dauerhaft behoben zu sein scheint, sollten Sie sich mit den Betreuern von msysgit in Verbindung setzen und prüfen, ob sie es herausfinden können die Ursache dieses Problems herausfinden.
Gemini14
3
Welche Bash-Konfigurationsdateien haben Sie genau gelöscht?
Scott
3
Dies ist nicht die Lösung für die Antwort. Wenn Sie eine Konfigurationsdatei deinstalliert und neu installiert haben, haben sich diese Änderungen möglicherweise geändert. Wenn Sie nur sagen, dass eine Neuinstallation die Lösung ist, ist dies falsch. Andere Personen deinstallieren und installieren möglicherweise neu und Konfigurationsdateien sind möglicherweise gleich. Deshalb funktioniert dies nicht für alle.
Carlos Calla
10

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

Chris Pawlukowsky
quelle
10
Die Frage spricht von Git Bash.
Manojlds
2
Sie können git bash als Administrator ausführen.
Dies
3
Wow, enorme Geschwindigkeitsverbesserung beim Ausführen von Git Bash als Administrator
Evil E
Ich bin mir nicht sicher, warum diese Antwort nur 6 Stimmen hat. Ich denke, diese Antwort hat das Problem vollständig gelöst. Es gibt eine enorme Geschwindigkeitsverbesserung.
vinoth10
2
@ vinoth10 Nun, es gibt ein Problem mit der Ausführung als Administrator. Was aus vielen Gründen eine schlechte Idee ist und für viele Unternehmensanwendungsfälle überhaupt keine Option ist. Das Lösen eines Leistungsproblems durch Erhöhen des Benutzers ist eine schreckliche Lösung.
JHH
6

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

sinelaw
quelle
Sie können auch die --shortOption verwenden, nicht zu druckenrefs/heads/
friederbluemle
@friederbluemle, welche Version von Git benutzt du? Meins (1.7.9) bietet nicht --shortfür den symbolic-refBefehl.
Sinelaw
Aktualisiert, um keine Fehler zu drucken, wenn sie sich außerhalb eines Git-Repos befinden, und um für getrennte HEADs zu arbeiten
sinelaw
Ich benutze 1.8.4 (msysgit)
friederbluemle
6

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

Olivier
quelle
5

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.

Nkosi Dean
quelle
4

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.

Codeherzen
quelle
2

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.

Eugene Pakhomov
quelle
2

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:

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

Rofrol
quelle
hat es nicht schneller gemacht
keinabel
@keinabel In diesem Moment würde ich core.commitGraph=truevon blogs.msdn.microsoft.com/devops/2018/06/25/… und anderen von blogs.msdn.microsoft.com/devops/tag/git
rofrol
2

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.

Binäres Phile
quelle
1
Das Ausschalten der Benutzerkontensteuerung scheint den "großen" Teil des Problems für uns zu lösen (Verzögerung von mehreren Sekunden). Der ps1-Hack erledigte den Rest.
Krosenvold
Ich bin auf SSD, 32 GB RAM und Quad Core i7 und keine der anderen Antworten hat geholfen. Deaktivierte
UAC-
2

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

Mastergalen
quelle
Ich möchte diese Tipps bestätigen. Git von Avast ausschließen macht die Sache wirklich schneller. Ich sehe den Git-Status, ohne mehr zu warten. Gewinnen Sie 7
x 64
Antivirenprogramme stören nur.
Alex78191
1
Danke, das war definitiv ein schneller Gewinn! Avast für 10 Minuten deaktiviert, bemerkte eine sofortige Änderung der Git-Leistung (dh Rückkehr zu normalen Ausführungszeiten).
Marcello Romani
Diese Lösung hat bei mir funktioniert. McAfee + Windows 10 Ent.
FractalSpace
1

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.

George
quelle
llein Alias ​​für sein log? Es scheint seltsam, dass es dafür DNS-Anfragen geben würde.
Michael - Wo ist Clay Shirky
1
llist ein Alias ​​für ls -l. Und es ist trotzdem seltsam, eine DNS-Anfrage auszulösen ... In der Zwischenzeit warte ich immer noch darauf, dass dieses Problem erneut auftritt, um der Antwort weitere Details hinzuzufügen.
George
1

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.

Mahacoder
quelle
Ich denke, diese Antwort sollte mehr Stimmen haben. Ich bin hierher gekommen, um die gleiche Empfehlung zu posten, aber ich habe gesehen, dass du mich schon geschlagen hast, lol.
Jon
0

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.

Koshmaar
quelle
Ihr Problem wurde also durch ein Skript verursacht, das Sie geschrieben hatten? Vielleicht ist dieses Skript nicht so wahrscheinlich die Ursache für andere Benutzer, die nach dem gleichen Problem suchen ...
Jolta
Schauen Sie sich die OP-Frage an - er erwähnte viele Dinge, die er überprüft hatte, und trotzdem war es nicht so. Das gleiche war bei mir. Also habe ich hier noch etwas hinzugefügt, das überprüft werden muss, wenn nichts hilft. Und nicht dieses spezielle Skript, das ich geschrieben habe, ist wichtig, sondern ein Konzept - schauen Sie sich Ihre PS1 an.
Koshmaar
0

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.

mrcl
quelle
0

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 .

bergmeister
quelle
Das hilft bei stash, aber dein Beitrag ist der erste, der stashspeziell erwähnt wird. Beeinflusst es andere Git-Operationen?
Michael - Wo ist Clay Shirky
Soweit ich weiß, nein. Es gibt zwei experimentelle Funktionen in der Vorschau, die es ermöglichen, eine native ausführbare Datei für eine bessere Leistung zu haben stashund / oder zu rebaseverwenden. Bei Vorschau besteht jedoch immer eine geringe Wahrscheinlichkeit, dass ein kleiner Nebeneffekt auftritt.
Bergmeister
1
PS Diese Funktion wurde in Version 2.19.1 nicht mehr in der Vorschau angezeigt, daher erhalten Sie keine Option mehr dafür
Bergmeister