Git Bash działa wyjątkowo wolno w systemie Windows 7 x64

435

Korzystałem z Git zarówno w systemie Windows, jak i Ubuntu podczas opracowywania małego projektu, często przerzucając się między nimi. Problem polega na tym, że Git Bash konsekwentnie staje się wolny.

Kiedy mówię powoli, mam na myśli, że bieganie cdzajmuje od 8 do 25 sekund, wykonywanie gitpoleceń trwa od 5 do 20 sekund, a lsczasem może trwać nawet do 30 sekund. Nie trzeba dodawać, że nie jest to zabawne, nie mówiąc już o bezproduktywności. Wiem, że Git działa wolniej w systemie Windows, ale jest to śmieszne.

Jedynym rozwiązaniem, które zadziałało - tymczasowo - było wyłączenie połączenia sieciowego (jak sugerowano w tej odpowiedzi ), uruchomienie Git Bash, a następnie ponowne połączenie. Czasami działa to szybko przez kilka dni po wykonaniu tej czynności, ale wydajność zawsze się pogarsza. Przeszukiwałem grupę dyskusyjną msysgit, przepełnienie stosu, listę problemów msysgit itp. Od tygodni, ale nie byłem w stanie znaleźć rozwiązań, które działają.

Do tej pory próbowałem:

  • Dodawanie folderów Git i projektów do listy wykluczeń skanera antywirusowego
  • Całkowite wyłączenie mojego skanera antywirusowego (Kaspersky IS 2011)
  • Zapewnianie, że program Outlook nie działa (Outlook 2007)
  • Zamykanie wszystkich innych aplikacji
  • Uruchamianie Git Bash jako administrator
  • Wyłączanie połączenia sieciowego, uruchamianie Git Bash i utrzymywanie połączenia wyłączone
  • Wyłączanie połączenia sieciowego, uruchamianie Git Bash, ponowne włączanie połączenia (działa tylko sporadycznie)
  • Bieganie git gc
  • I kombinacje powyższych

Czytałem, że kilka osób odniosło sukces, uniemożliwiając ukończenie Bash, ale idealnie chciałbym zachować tę aktywność. Wersja msysgit to 1.7.3.1-Preview20101002, a system operacyjny to Windows 7 x64. Uruchamianie tych samych rzeczy w systemie Linux jest błyskawicznie szybkie. Używałbym wyłącznie Linuksa, ale muszę też uruchamiać rzeczy w Windowsie (niektóre aplikacje, testy itp.).

Czy ktoś napotkał podobny problem? Jeśli tak, jaki był problem podstawowy i jakie było rozwiązanie (jeśli w ogóle)?

Dotyczy to nie tylko repozytoriów Git, ale dla porównania, repozytoria, z których korzystam z Git, są dość małe: maksymalnie 4-50 plików.

Gemini14
źródło
1
Aby Cię nie zniechęcić, ale Cygwin działa bardzo wolno na platformie x64, lepiej wypróbuj ją w systemie Windows XP 32bit.
ismail
2
możliwy duplikat Msysgit bash jest strasznie powolny w Windows 7
childno͡.de
5
W tym samym systemie pół roku temu nie było to wolne. Musieli coś zmienić ...
Tomáš Zato - Przywróć Monikę
2
Na praktycznie wszystkich maszynach tutaj: Kaspersky AV znacznie spowalnia git i „wyłącza” Kaspersky jest zepsuty, avp.exe nadal działa po całkowitym wyjściu z niego. Całkowita ponowna instalacja kaspersky zazwyczaj rozwiązuje ten drugi problem.
peterchen
2
Zobacz stronę wiki msysgit
Drew Noakes

Odpowiedzi:

409

Możesz znacznie przyspieszyć Git w systemie Windows, uruchamiając trzy polecenia, aby ustawić niektóre opcje konfiguracji:

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

Uwagi:

  • core.preloadindex wykonuje równolegle operacje systemu plików, aby ukryć opóźnienia (aktualizacja: domyślnie włączona w Git 2.1)

  • core.fscache naprawia problemy UAC, więc nie trzeba uruchamiać Gita jako administrator (aktualizacja: domyślnie włączona w Git dla Windows 2.8)

  • gc.auto minimalizuje liczbę plików w .git /

szewc
źródło
Nie pomógł mi, ale pomógł w eksporcie PS1 = „$” wymienionym poniżej. Więc wiem, że problemem jest linia terminalowa.
Koshmaar
67
Całkowicie bezużyteczne ustawienia w 2017 roku (git 2.12), ponieważ wszystkie te rzeczy są domyślnie włączone. Ale dupek nadal działa powoli jak gówno.
tj. Z wyjątkiem
2
Działa świetnie również w systemie Windows 10. Dobra robota i dziękuję za to @shoelzer!
Joe
1
Ograniczenie plików do 256 może powodować pewne problemy. Dwie pierwsze opcje są już włączone w nowych wersjach git.
nPcomp
@sonyvizio Jakie problemy?
szewc
102

Czy masz informacje Git wyświetlane w wierszu polecenia Bash? Jeśli tak, może przypadkowo wykonujesz za dużo pracy przy każdym poleceniu. Aby przetestować tę teorię, wypróbuj następującą tymczasową zmianę w Bash:

export PS1='$'
Chris Dolan
źródło
11
Problem polega na $(__git_ps1)... usunięciu tego sprawia, że ​​wszystko jest superszybkie
Hendy Irawan
10
Dla niewtajemniczonych wśród nas, co dokładnie robi to polecenie? Mówisz, że to „tymczasowe”, w jaki sposób cofamy polecenie?
Immortal Blue
5
Naprawiłem także problemy z wydajnością. Aby naprawić na stałe, edytuj C:\Program Files (x86\Git\etc\profilei komentuj if-then-else, gdzie __git_ps1jest dodawany PS1.
Tom
6
W bieżącej wersji 2.18.0 nie mogę znaleźć polecenia __git_ps1 w / etc / profile. Czy przeniósł się gdzieś indziej?
keinabel
8
Wygląda na to, że został przeniesiony do C: \ Program Files \ Git \ etc \ profile.d \ git-prompt.sh. Skomentowałem __git_ps1 w tym pliku i poszło znacznie szybciej (ale zgubiłem informacje o oddziale w odpowiedzi)
Miyagi,
85

Mój katalog domowy Windows znajduje się w sieci i podejrzewałem, że polecenia Git Bash szukały go najpierw. Rzeczywiście, kiedy spojrzałem $PATH, /h/binnajpierw wymieniono , gdzie /hjest udział na serwerze plików Windows, chociaż /h/binnie istnieje.
Zredagowałem /etc/profilei skomentowałem polecenie eksportu, które stawia je na pierwszym miejscu $PATH:

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

Dzięki temu moje polecenia działały znacznie szybciej, prawdopodobnie dlatego, że Git Bash nie szuka już w sieci plików wykonywalnych. Mój /etc/profilebył c:\Program Files (x86)\Git\etc\profile.

Rob Johnson
źródło
6
Miałem ten sam problem. Zmieniłem się HOME="$(cd "$HOME" ; pwd)"na HOME="$(cd "$USERPROFILE" ; pwd)"i teraz wszystko jest niesamowicie szybkie. Dzięki za wskazówkę.
Jon Sagara,
2
Udało mi się użyć tego wariantu: w profilu zmuś $ HOME do $ USERPROFILE, usuwając odwołanie do $ HOMEDRIVE. Również we właściwościach skrótu Git Bash ustaw „Start za” na% USERPROFILE%
Aidan Ryan,
11
To w większości rozwiązało mój problem, ale w Git przynajmniej od wersji 2.7.2 znalazłem ten eksport w /etc/profile.d/env.sh zamiast bezpośrednio w pliku / etc / profile.
Jared Siirila
15
Dziękuję bardzo za ten sam problem, jednak naprawiłem go, tworząc zmienną środowiskową (użytkownika) o nazwie HOME, wskazując na mój pożądany katalog domowy. Jeśli $ HOME nie jest obecny, najwyraźniej git bash domyślnie ustawi się na% USERPROFILE%. Po tym git bash jest błyskawiczny.
JHH
6
Jedyną opcją, która działała, była opcja @JHH opisana w komentarzach. Dodaj zmienną środowiskową użytkownika systemu Windows o nazwie HOME i zdefiniuj żądany katalog domowy. (Panel sterowania -> System -> Zaawansowane ustawienia systemu -> Zmienne środowiskowe)
RenRen 12.04.17
45

Odkryłem, że dysk sieciowy jest problemem z wydajnością. HOMEwskazywał na wolny udział sieciowy. Nie mogłem zastąpić, HOMEDRIVEale to nie jest problem z tego, co widziałem.

Ustaw zmienną środowiskową, klikając prawym przyciskiem myszy komputer na pulpicie -> właściwości -> Zaawansowane ustawienia systemowe -> Zmienne środowiskowe Dodaj do sekcji Zmienne użytkownika

HOME=%USERPROFILE%
MichaelK
źródło
4
To zadziałało. Dla każdego, kto ma problem z siecią, jest to prawdziwe rozwiązanie. Nie musisz edytować żadnego pliku konfiguracyjnego, po prostu ustaw HOME w odpowiednim miejscu.
Carlos Calla
1
Definiowanie env User Var HOME jako% USERPROFILE% nie działało. Zdefiniowałem zmienną
systemową
Pracował dla mnie! Dzięki. Zrobiłem coś takiego jak @colin_froggatt, ale zamiast tego zmienne środowiskowe użytkownika, ustawiając HOME = C: \ Users \ myUserName
Ð ..
22

W rozszerzeniu odpowiedzi Chrisa Dolana zastosowałem następujące PS1ustawienie alternatywne . Po prostu dodaj fragment kodu do ~ / .profile (w 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\]
$ '

Zachowuje to zaletę kolorowej powłoki i wyświetlania bieżącej nazwy gałęzi (jeśli jest w repozytorium Git), ale na mojej maszynie jest znacznie szybszy, od ~ 0,75 s do 0,1 s.

Jest to oparte na tym blogu .

Wilbert
źródło
Świetna odpowiedź. Jednak postanowiłem przedefiniować '__git_ps1 ()' w moim ~ / .bashrc i po prostu wydrukować pusty ciąg. Przyspiesza wszystkie polecenia Bash.
ajukraine
Jestem początkującym gitarzystą, chciałbym wiedzieć, jaka jest różnica między tym fast_git_ps1 a oryginalnym dość skomplikowanym __git_ps1. Rozumiem, że to zadziała w większości „normalnych” przypadków, ale co jest normalne i gdzie to się nie powiedzie?
sundar - Przywróć Monikę
Nie znam przypadków, w których się nie powiedzie. Wcześniej używałem __git_ps1, ale zauważyłem problemy z wydajnością, więc majstrowałem, próbując zmusić gita do mniejszej pracy, aby wyodrębnić wyświetlane informacje.
Wilbert,
2
Oryginał __git_ps1zawiera informacje o stanie, a nie tylko nazwę oddziału. Na przykład, jeśli jesteś w stanie oderwania głowy, w git dir, w nagim repo, w trakcie zbierania wiśni lub zmiany lub scalenia ... Będzie to szybsze, ale mogą być sytuacje, w których będziesz tęsknić te dodatkowe informacje, szczególnie jako początkujący Git.
Drew Noakes,
22

Chociaż problem może dotyczyć sieci, osobiście przyspieszyłem git statusdziesięciokrotnie moje połączenia lokalne (7+ sekund do 700 ms), dokonując dwóch modyfikacji. Jest to repozytorium o pojemności 700 MB z 21 000 plików i nadmierną liczbą dużych plików binarnych.

Jednym z nich jest włączenie wstępnego ładowania indeksu równoległego. Z wiersza polecenia:

git config core.preloadindex true
Zmieniło się to time git statusz 7 sekund do 2,5 sekundy.

Aktualizacja!

Poniższe nie jest już konieczne. Łatka naprawiła to od wersji mysysgit 1.9.4
https://github.com/msysgit/git/commit/64d63240762df22e92b287b145d75a0d68a66988
Jednak należy włączyć poprawkę, wpisując
git config core.fscache true

Wyłączyłem także UAC i sterownik „luafv” (wymagane ponowne uruchomienie). Wyłącza to sterownik w systemie Windows Vista, 7 i 8, który przekierowuje programy próbujące zapisywać do lokalizacji systemowych, a zamiast tego przekierowuje dostęp do katalogu użytkownika.

Aby zobaczyć dyskusję na temat tego, jak wpływa to na wydajność Gita, przeczytaj tutaj: https://code.google.com/p/msysgit/issues/detail?id=320

Aby wyłączyć ten sterownik, w regedit zmień klawisz „start” na HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/luafv4, aby wyłączyć sterownik. Następnie ustaw UAC na najniższe ustawienie, „nigdy nie powiadamiaj”.

Jeśli wyłączenie tego sterownika powoduje, że jesteś ostrożny (powinien), alternatywa działa na dysku (lub partycji) innej niż partycja systemowa. Najwyraźniej sterownik działa tylko w przypadku dostępu do plików na partycji systemowej. Mam drugi dysk twardy i widzę identyczne wyniki po uruchomieniu z tą modyfikacją rejestru na moim dysku C, jak robię to bez niego na dysku D.

Ta zmiana trwa time git statusod 2,5 sekundy do 0,7 sekundy.

Możesz także śledzić https://github.com/msysgit/git/pull/94 i https://github.com/git/git/commit/d637d1b9a8fb765a8542e69bd2e04b3e229f663b, aby sprawdzić, jakie dodatkowe prace są prowadzone w związku z problemami z szybkością w systemie Windows .

Jeff Lamb
źródło
10
to jeszcze raz uwidacznia idiotów i potworne rozwiązania Microsoft, problemy rozwiązane w Unixie w prosty i elegancki sposób w 1968 roku. Ile wysiłku produkcyjnego, czasu i pieniędzy zmarnował wzdęcie Microsoftu i brak refaktoryzacji / elastyczności / audacity na całym świecie?
v.oddou
20
Pamiętam, jak używałem gita w 68 roku, było wspaniale.
Charlie Brown
2
Haha na rok przed pojawieniem się Linusa @CharlieBrown
cchamberlain
1
włączone domyślnie w git 2.1 stackoverflow.com/a/24045966/4854931
Alex78191
18

Wygląda na to, że całkowite odinstalowanie Gita, ponowne uruchomienie (klasyczne lekarstwo na system Windows) i ponowna instalacja Git była lekarstwem. Wyczyściłem również wszystkie pliki konfiguracyjne bash, które pozostały (zostały ręcznie utworzone). Wszystko znów jest szybkie.

Jeśli z jakiegoś powodu ponowna instalacja nie jest możliwa (lub pożądana), to zdecydowanie spróbowałbym zmienić zmienną PS1 wymienioną w odpowiedzi Chrisa Dolana ; spowodowało znaczne przyspieszenie niektórych operacji.

Gemini14
źródło
3
Ponowna instalacja bez ponownego uruchomienia nie działała, odinstalowanie-ponowne uruchomienie-instalacja zadziałało. Dzięki! Byłoby miło wiedzieć, dlaczego i jak bash jest tak wolny.
Gauthier
Ponowne zainstalowanie z ponownym uruchomieniem nie miało dla mnie znaczenia.
RyanW,
@RyanW Obawiam się, że nie mogę pomóc poza powyższym rozwiązaniem, które zadziałało dla mnie, ale ponieważ wydaje się, że ten problem nie został jeszcze na stałe rozwiązany, możesz skontaktować się z opiekunami msysgit i sprawdzić, czy mogą to zrozumieć z przyczyny tego problemu.
Gemini14
3
Które pliki konfiguracyjne bash dokładnie wymazałeś?
Scott
3
To nie jest rozwiązanie odpowiedzi. Po odinstalowaniu i ponownym zainstalowaniu niektórych plików konfiguracyjnych mogły ulec zmianie, te zmiany są odpowiedzią. Jeśli powiesz tylko, że ponowna instalacja jest rozwiązaniem, to jest źle. Inne osoby mogą odinstalować i ponownie zainstalować, a pliki konfiguracyjne mogą być takie same i dlatego nie będzie działać dla wszystkich.
Carlos Calla,
10

Rozwiązałem mój wolny problem z Git na Windows 7 x64, uruchamiając cmd.exe z „Uruchom jako administrator”.

Chris Pawlukowsky
źródło
10
Pytanie mówi o git bash.
manojlds
2
Możesz uruchomić git bash jako administrator; co może wydawać się wskazywać na problem UAC
krosenvold,
3
Wow, ogromna poprawa prędkości podczas uruchamiania git bash jako administrator
Złe E
Nie jestem pewien, dlaczego ta odpowiedź ma tylko 6 głosów. Myślę, że ta odpowiedź całkowicie rozwiązała problem. Istnieje ogromna poprawa prędkości.
vinoth10,
2
@ vinoth10 Cóż, jest problem z, wiesz, działaniem jako administrator. Co z wielu powodów jest złym pomysłem i dla wielu firmowych przypadków użycia w ogóle nie wchodzi w grę. Rozwiązanie problemu z wydajnością przez podniesienie użytkownika jest okropnym rozwiązaniem.
JHH
6

Jak zauważono w odpowiedziach Chrisa Dolana i Wilberta, PS1 spowalnia cię .

Zamiast całkowicie wyłączać (jak sugeruje Dolan) lub używać skryptu oferowanego przez Wilberta, używam „głupiego PS1”, który jest znacznie szybszy.

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

W moim Cygwinie jest to szybsze niż odpowiedź „fast_Git_PS1” Wilberta - 200 ms w porównaniu do 400 ms, więc goli trochę twoją szybką powolność.

Nie jest tak wyrafinowany jak __git_ps1- na przykład nie zmienia monitu, gdy przechodzisz do katalogu .git itp., Ale do normalnego codziennego użytku jest wystarczająco dobry i szybki.

Zostało to przetestowane na Git 1.7.9 (Cygwin, ale powinno działać na dowolnej platformie).

sinelaw
źródło
Możesz także użyć --shortopcji, aby nie drukowaćrefs/heads/
friederbluemle
@friederbluemle, jakiej wersji git używasz? Mine (1.7.9) nie oferuje --shortdla symbolic-refkomendy.
sinelaw
Zaktualizowano, aby nie drukował błędów poza repozytorium git i działał dla odłączonych HEAD
sinelaw,
Używam 1.8.4 (
msysgit
6

Możesz również zyskać bardzo subtelny wzrost wydajności, zmieniając następującą konfigurację Git:

git config --global status.submoduleSummary false

Po uruchomieniu prostej git statuskomendy w systemie Windows 7 x64 uruchomienie komputera zajęło mi ponad 30 sekund. Po zdefiniowaniu tej opcji polecenie jest natychmiastowe.

Aktywacja własnego śledzenia Gita, jak wyjaśniono na poniższej stronie, pomogła mi znaleźć źródło problemu, który może różnić się w twojej instalacji: https://github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is-so- powolny

Olivier
źródło
5

Miałem ten sam problem, zarówno w Git Bash, jak i Git GUI. Oba programy ładnie działają, ale potem losowo zwolniły do ​​indeksowania i nie mogłem zrozumieć, dlaczego.

Jak się okazuje, był to Avast. Avast spowodował dziwne rzeczy, które przydarzyły się różnym programom (w tym programom, które piszę), więc wyłączyłem go na sekundę i oczywiście Bash działa teraz tak szybko, jak na Linuksie. Właśnie dodałem folder plików programu Git ( C:\Program Files\Git) do listy wykluczeń Avast, a teraz działa tak szybko, jak w Linuksie.

I tak, zdaję sobie sprawę, że oprogramowanie antywirusowe nie było problemem w oryginalnym poście, ale po prostu umieszczę to tutaj na wypadek, gdyby było to przydatne dla kogoś.

Nkosi Dean
źródło
4

Oprócz tych innych odpowiedzi przyspieszyłem projekty z wieloma podmodułami, używając równoległego pobierania modułów (od Gita 2.8 na początku 2016 r.).

Można tego dokonać git fetch --recurse-submodules -j8i ustawić za pomocą git config --global submodule.fetchJobs 8, lub niezależnie od tego, ile rdzeni masz / chcesz użyć.

serca kodowe
źródło
2

Jeśli używasz Git z cmd, spróbuj uruchomić go z Git Bash. W cmd git.exe to tak naprawdę opakowanie, które konfiguruje właściwe środowisko za każdym razem, gdy go uruchamiasz, a dopiero potem uruchamia prawdziwy git.exe. Może to zająć nawet dwa razy więcej czasu, niż potrzeba, aby zrobić to, co chcesz. A Git Bash konfiguruje środowisko dopiero po uruchomieniu.

Eugene Pakhomov
źródło
2

Połączone odpowiedzi:

  1. Wilbert's - jakie informacje zawrzeć w PS1
  2. sinelaw's - (<branch_name>)lub(<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}\] $ '

Wynik:

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

rofrol
źródło
nie przyspieszyło
keinabel
@keinabel W tym momencie chciałbym przyjrzeć się core.commitGraph=truez blogs.msdn.microsoft.com/devops/2018/06/25/... i inne z blogs.msdn.microsoft.com/devops/tag/git
rofrol
2

Ten sam problem z uruchomieniem Git dla Windows (msysgit) na Windows 7 x64 jako konto z ograniczonym kontem użytkownika od dłuższego czasu.

Z tego, co przeczytałem tutaj i innych miejscach, wspólnym tematem wydaje się być brak uprawnień administracyjnych i / lub UAC. Ponieważ UAC jest wyłączony w moim systemie, wyjaśnienie, że próbuje coś zapisać / usunąć coś w katalogu plików programów, jest dla mnie najbardziej sensowne.

W każdym razie rozwiązałem problem, instalując przenośną wersję Git 1.8 z programem zipinstaller. Zauważ, że musiałem rozpakować plik dystrybucyjny .7z i ponownie go spakować jako plik ZIP, aby zipinstaller działał. Musiałem też ręcznie dodać ten katalog do ścieżki systemowej.

Wydajność jest teraz w porządku. Mimo że jest zainstalowany w Program Files (x86)katalogu, do którego nie mam uprawnień jako ograniczony użytkownik, wydaje się, że nie cierpi z powodu tego samego problemu.

Przypisuję to albo faktowi, że wersja przenośna jest nieco bardziej konserwatywna w przypadku zapisywania / usuwania plików, co prawdopodobnie ma miejsce, albo aktualizacji z wersji 1.7 do 1.8. Nie zamierzam określać, który jest powodem, wystarczy powiedzieć, że teraz działa znacznie lepiej, w tym Bash.

Binarny Phile
źródło
1
Wyłączenie UAC wydaje się rozwiązać dla nas „dużą” część problemu (wielosekundowe opóźnienie). Hack ps1 zrobił resztę.
krosenvold
Tak samo jestem na SSD, 32 GB pamięci RAM i quad core i7 i żadna inna odpowiedź nie pomogła, wyłączone UAC, restart i polecenia git są NATYCHMIASTOWE
phil_lgr
2

W moim przypadku był to program antywirusowy Avast prowadzący do Git Bash, a nawet PowerShell stał się naprawdę wolny.

Najpierw próbowałem wyłączyć Avast na 10 minut, aby sprawdzić, czy poprawiła prędkość i tak się stało. Następnie dodałem cały katalog instalacyjny Git Bash jako wyjątek w Avast, do odczytu, zapisu i wykonania. W moim przypadku tak było C:\Program Files\Git\*.

Mastergalen
źródło
Chcę potwierdzić te wskazówki. Wyklucz git z Avast, aby naprawdę przyspieszyć. Widzę status git bez czekania. Wygraj 7 x64
fajarhac
Antywirusy tylko przeszkadzają.
Alex78191
1
Dzięki, to była zdecydowanie szybka wygrana! Wyłączono avast na 10 minut, zauważyłem natychmiastową zmianę wydajności git (tj. Powrót do normalnych czasów wykonywania).
Marcello Romani
To rozwiązanie działało dla mnie. McAfee + Windows 10 Ent.
FractalSpace
1

Nic z powyższych nie było w stanie mi pomóc. W moim scenariuszu problem wyglądał następująco:

  • Każde llpolecenie działało powoli (wykonanie trwało około 3 sekund)
  • Każde kolejne llpolecenie zostało wykonane natychmiast, ale tylko w ciągu 45 sekund od poprzedniego polecenia ls .

Jeśli chodzi o debugowanie za pomocą Monitora procesów , okazało się, że przed każdym poleceniem było żądanie DNS.

Gdy tylko wyłączyłem zaporę (w moim przypadku Comodo) i pozwoliłem, aby polecenie wykonało problem, problem zniknął. I nie wraca z powrotem, gdy zapora została ponownie włączona. Przy najbliższej okazji zaktualizuję tę odpowiedź, podając więcej szczegółów na temat tego, co proces blokował żądanie DNS i jaki był cel.

BR, G

Jerzy
źródło
llbędąc pseudonimem log? Wydaje się dziwne, że byłyby do tego żądania DNS.
Michael - Where's Clay Shirky
1
lljest pseudonimem dla ls -l. I tak nadal dziwne jest wywołanie żądania DNS ... Tymczasem wciąż czekam na ponowne pojawienie się tego problemu, aby dodać więcej szczegółów do odpowiedzi.
George
1

W moim przypadku skrót Git Bash został ustawiony na Start in:%HOMEDRIVE%%HOMEPATH%(możesz to sprawdzić, klikając prawym przyciskiem myszy Git Bash i wybierając właściwości). To był dysk sieciowy.

Rozwiązaniem jest wskazanie tego %HOME%. Jeśli go nie masz, możesz ustawić go w zmiennych środowiskowych, a teraz Git Bash powinien być błyskawiczny.

mahacoder
źródło
Myślę, że ta odpowiedź powinna mieć więcej głosów. Przyszedłem tutaj, aby opublikować tę samą rekomendację, ale widziałem, że już mnie pobiłeś, lol.
Jon
0

Miałem również problem ze spowolnieniem git PS1, chociaż przez długi czas myślałem, że to problem z wielkością bazy danych (duże repozytorium) i próbowałem różnych git gcsztuczek, i szukałem innych powodów, takich jak ty. Jednak w moim przypadku problemem był ten wiersz:

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
}

Wykonanie git statusdla każdej linii statusu linii poleceń było powolne. Auć. To było coś, co napisałem ręcznie. Widziałem, że to był problem, kiedy próbowałem

export PS1='$'

jak wspomniano w jednej odpowiedzi tutaj. Linia poleceń była błyskawiczna.

Teraz używam tego:

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

Z linii Przepełnienie stosu po linii PS1 z bieżącym odgałęzieniem i kolorami i działa dobrze. Znowu masz szybką linię poleceń Git.

Kosmaar
źródło
Więc twój problem został spowodowany przez skrypt, który napisałeś? Być może ten skrypt nie jest tak prawdopodobną przyczyną dla innych użytkowników, którzy szukają tego samego problemu ...
Jolta,
Spójrz na pytanie OP - wspomniał o wielu rzeczach, które sprawdził, a jednak to nie było to. Tak samo było ze mną. Więc tutaj dodałem kolejną rzecz do sprawdzenia, kiedy nic nie pomoże. Ważny jest nie ten skrypt, który napisałem, ale koncepcja - spójrz na swoją konsolę PS1.
Koshmaar,
0

Mój współpracownik miał problemy z Git na Windowsie (7) git status checkouti addbył szybki, ale git commitzajął wieki.

Nadal próbujemy znaleźć przyczynę tego problemu, ale klonowanie repozytorium w nowym folderze naprawiło jego problem.

mrcl
źródło
0

Jak wielu powiedziało, wynika to z faktu, że stashjest to skrypt powłoki w systemie Windows, ale od wersji Git 2.18.0 instalator Windows ma opcję eksperymentalnej funkcji znacznie szybszej (~ 90%) wbudowanej wersji skrytki - https: / /github.com/git-for-windows/build-extra/pull/203 .

bergmeister
źródło
To pomaga stash, ale twój jest pierwszym, który wspomina stashkonkretnie. Czy wpływa to na inne operacje Git?
Michael - Where's Clay Shirky
O ile rozumiem, nie. W podglądzie znajdują się 2 eksperymentalne funkcje, które pozwalają mieć stashi / lub rebaseużywać natywnego pliku wykonywalnego w celu uzyskania lepszej wydajności, ale przy czymkolwiek w podglądzie zawsze istnieje niewielka szansa, że ​​może wystąpić niewielki efekt uboczny.
bergmeister
1
PS Ta funkcja wyszła z podglądu w wersji 2.19.1, dlatego nie ma już dla niej opcji
bergmeister,