Git Bash, Windows 7 x64'te son derece yavaş

Git'i hem Windows hem de Ubuntu'da küçük bir projenin geliştirilmesi sırasında kullanıyorum, sık sık ikisi arasında gidip geliyor. Sorun Git Bash'ın sürekli yavaşlaması.

Yavaş cddediğimde, koşmanın 8-25 saniye arasında, koşma gitkomutlarının 5-20 saniye sürdüğünü ve lsbazen 30 saniyeye kadar sürebileceğini kastediyorum . Söylemeye gerek yok, bu verimsiz değil, eğlenceli değil. Git'in Windows'ta daha yavaş olduğunu biliyorum, ama bu çok saçma.

Geçici olarak benim için çalışan tek çözüm ağ bağlantımı devre dışı bırakmak ( bu cevapta önerildiği gibi ), Git Bash'i başlatmak ve ardından yeniden bağlanmaktı. Bazen bunu yaptıktan sonra günlerce hızlı bir şekilde çalışmaya devam eder, ancak performans her zaman sonunda düşer. Haftalarca msysgit tartışma grubu, Stack Overflow, msysgit sayı listesi vb. İle açtım ve kapadım, ancak işe yarayan çözümleri açamadım.

Şimdiye kadar denedim:

• Git ve proje klasörlerini virüs tarayıcının hariç tutma listesine ekleme
• Virüs tarayıcımı tamamen devre dışı bırakma (Kaspersky IS 2011)
• Outlook'un çalışmadığından emin olma (Outlook 2007)
• Diğer tüm uygulamaları kapatma
• Git Bash'ı yönetici olarak çalıştırma
• Ağ bağlantısını devre dışı bırakma, Git Bash'i başlatma ve bağlantıyı devre dışı bırakma
• Ağ bağlantısını devre dışı bırakma, Git Bash'i başlatma, bağlantıyı yeniden etkinleştirme (yalnızca ara sıra çalışır)
• Koşu git gc
• Ve yukarıdakilerin kombinasyonları

Bash'in tamamlanmasını devre dışı bırakan birkaç kişinin başarılı olduğunu okudum, ama ideal olarak bunu aktif tutmak istiyorum. Msysgit sürümü 1.7.3.1-önizleme20101002 ve işletim sistemi Windows 7 x64'tür. Aynı şeyleri Linux'ta çalıştırmak tahmin edilebilir bir şekilde hızlıdır. Yalnızca Linux'u kullanırım, ancak Windows'da da bazı şeyler çalıştırmam gerekiyor (belirli uygulamalar, testler vb.).

Benzer bir sorunla karşılaşan var mı? Eğer öyleyse, temel sorun neydi ve çözüm neydi (eğer varsa)?

Bu sadece Git depolarının ötesine uzanır, ancak sadece referans olarak, Git'i kullandığım depolar oldukça küçüktür: maksimum ~ 4-50 dosya.

Bazı yapılandırma seçeneklerini ayarlamak için üç komut çalıştırarak Git'i Windows'da önemli ölçüde hızlandırabilirsiniz:

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

Notlar:

• core.preloadindex dosya sistemi işlemleri gecikmeyi gizler mi? (güncelleme: Git 2.1'de varsayılan olarak etkindir)

• core.fscache Git'i yönetici olarak çalıştırmanıza gerek kalmaması için UAC sorunlarını giderir (güncelleme: Windows 2.8 için Git'te varsayılan olarak etkindir)

• gc.auto .git / içindeki dosya sayısını en aza indirir

Bash isteminde Git bilgisinin var mı? Eğer öyleyse, belki her komutta yanlışlıkla çok fazla iş yapıyorsunuzdur. Bu teoriyi test etmek için Bash'te aşağıdaki geçici değişikliği deneyin:

export PS1='$'

Windows ana dizinim ağda ve Git Bash komutlarının önce oraya baktığından şüphelendim. Tabii ki, baktığımda, ilk önce $PATHlistelenmişti, ancak Windows dosya sunucusunda bir paylaşım var, ancak mevcut değil. Ben ilk koyar ihracat komutunu düzenledi ve yorum yaptı :/h/bin/h/h/bin
/etc/profile$PATH

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

Bu, komutlarımın çok daha hızlı çalışmasını sağladı, çünkü Git Bash artık ağda çalıştırılabilir dosyaları aramıyor. Benim /etc/profileoldu c:\Program Files (x86)\Git\etc\profile.

Ağ sürücüsünün performans sorunu olduğunu gördüm. HOMEyavaş bir ağ paylaşımına işaret ediyordu. Geçersiz kılmadım HOMEDRIVEama bu gördüğümden bir sorun değil.

Bilgisayarınızı masaüstünde sağ tıklatarak ortam değişkenini ayarlayın -> özellikler -> Gelişmiş sistem ayarları -> Ortam Değişkenleri Kullanıcı değişkenlerine ekle bölümü

HOME=%USERPROFILE%

Chris Dolan'ın cevabının bir uzantısı olarak, aşağıdaki alternatif PS1ayarı kullandım. Kod parçasını ~ / .profile dosyasına eklemeniz yeterlidir (Windows 7'de: 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\]
$ '

Bu, renkli bir kabuktan yararlanır ve geçerli dal adının görüntülenmesini sağlar (Git deposundaysa), ancak makinemde ~ 0.75 s'den 0.1 s'ye kadar önemli ölçüde daha hızlıdır.

Bu, bu blog yayınına dayanmaktadır .

Sorununuz ağ tabanlı olsa da, git statusiki modifikasyon yaparak şahsen yerel çağrılarımı on kat (7+ saniye 700 ms'ye kadar) hızlandırdım . Bu, 21.000 dosya ve çok sayıda büyük ikili dosya içeren 700 MB'lık bir depoda.

Birincisi paralel indeks önyüklemelerini mümkün kılmak Bir komut isteminden:

git config core.preloadindex true
Bu time git status7 saniyeden 2,5 saniyeye değiştirildi.

Güncelleme!

Aşağıdakiler artık gerekli değildir. Düzeltme eki mysysgit 1.9.4 itibarıyla düzeltildi
https://github.com/msysgit/git/commit/64d63240762df22e92b287b145d75a0d68a66988
Ancak, yazarak düzeltmeyi etkinleştirmeniz gerekir
git config core.fscache true

Ayrıca UAC ve "luafv" sürücüsünü de devre dışı bıraktım (yeniden başlatma gerekir). Bu, Windows Vista, 7 ve 8'de sistem konumlarına yazmaya çalışan programları ve bunun yerine bir kullanıcı dizinine yeniden yönlendiren bir sürücüyü devre dışı bırakır.

Bunun Git performansını nasıl etkilediğiyle ilgili bir tartışma görmek için burayı okuyun: https://code.google.com/p/msysgit/issues/detail?id=320

Bu sürücüyü devre dışı bırakmak için, regedit'te "start" tuşunu HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/luafv 4 olarak değiştirin. Ardından, UAC'yi en düşük ayara getirin, "asla bildirmeyin".

Bu sürücünün devre dışı bırakılması sizi endişelendiriyorsa (gerekir), bir sürücü (veya bölüm) üzerinde sistem bölümünüzden farklı bir alternatif çalışıyor. Görünüşe göre sürücü sadece sistem bölümündeki dosya erişimi üzerinde çalışıyor. Ben ikinci bir sabit disk var ve ben D sürücüsünde yaptığım gibi benim C sürücüsünde bu kayıt defteri değişiklik ile çalışırken aynı sonuçları görmek.

Bu değişiklik time git status2,5 saniyeden 0,7 saniyeye kadar sürer.

Windows'ta hız sorunları için hangi ek çalışmanın sürdüğünü kontrol etmek için https://github.com/msysgit/git/pull/94 ve https://github.com/git/git/commit/d637d1b9a8fb765a8542e69bd2e04b3e229f663b adresini de takip etmek isteyebilirsiniz. .

Git'in tamamen kaldırılması, yeniden başlatılması (klasik Windows kürü) ve Git'in yeniden kurulmasının çaredir. Ayrıca kalan tüm bash yapılandırma dosyalarını da sildim (manuel olarak oluşturuldular). Her şey tekrar hızlı.

Herhangi bir nedenden dolayı yeniden yükleme mümkün değilse (veya arzu edilirse), kesinlikle Chris Dolan'ın cevabında belirtilen PS1 değişkenini değiştirmeyi denerim ; bazı operasyonlarda önemli hızlanmalara neden oldu.

Windows 7 x64'te yavaş Git sorunumu cmd.exe'yi "Yönetici olarak çalıştır" ile başlatarak çözdüm.

Burada önerildiği gibi core.preloadindex değerini true olarak ayarlayarak iyi bir gelişme gördüm .

Chris Dolan ve Wilbert'in cevaplarında belirtildiği gibi, PS1 sizi yavaşlatır .

Tamamen devre dışı bırakmak (Dolan'ın önerdiği gibi) ya da Wilbert tarafından sunulan senaryoyu kullanmak yerine, çok daha hızlı bir "aptal PS1" kullanıyorum.

Kullanır (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\]# '

Cygwin'imde bu, Wilbert'in "fast_Git_PS1" cevabından daha hızlı - 200 ms'ye karşı 400 msn, bu yüzden hızlı halsizliğinizden biraz kurtulun .

Bu kadar sofistike değildir __git_ps1- örneğin .git dizinine vb. Girdiğinizde istemi değiştirmez, ancak normal günlük kullanım için yeterince iyi ve hızlıdır.

Bu Git 1.7.9'da test edildi (Cygwin, ancak herhangi bir platformda çalışması gerekir).

Aşağıdaki Git yapılandırmasını değiştirerek çok düşük performans artışı da elde edebilirsiniz:

git config --global status.submoduleSummary false

Basit çalıştırırken git statusWindows 7 x64'te komutu bilgisayarımın çalışması 30 saniyeden uzun sürdü. Bu seçenek tanımlandıktan sonra komut hemen gerçekleşir.

Git'in aşağıdaki sayfada açıklandığı şekilde kendi izlemesini etkinleştirmek, sorunun kaynağını bulmanıza yardımcı oldu, bu da kurulumunuzda farklılık gösterebilir: https://github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is-so- yavaş

Hem Git Bash hem de Git GUI'de aynı sorunu yaşıyordum. Her iki program da güzelce çalışıyor, ancak sonra rastgele bir taramaya yavaşladılar ve nedenini bulamadım.

Anlaşıldığı üzere Avast'tı. Avast, çeşitli programlarda (yazdığım programlar dahil) garip şeyler olmasına neden oldu, bu yüzden bir saniye boyunca devre dışı bıraktım ve yeterince eminim, Bash artık Linux'ta olduğu kadar hızlı çalışıyor. Git program dosyaları klasörünü yeni ekledim (C:\Program Files\Git ) Avast hariç tutma listesine ve şimdi Linux'ta olduğu kadar hızlı çalışıyor.

Ve evet, antivirüs yazılımının orijinal yayında sorun olmadığını anlıyorum, ancak birileri için yararlı olması durumunda bunu buraya koyacağım.

Bu diğer cevaplara ek olarak, paralel alt modül getirme kullanarak birden fazla alt modüllü projeler hızlandırdım (2016 başında Git 2.8'den beri).

Bu yapılabilir git fetch --recurse-submodules -j8ve ayarlanabilir git config --global submodule.fetchJobs 8veya bununla birlikte kullanmak istediğiniz / kullanmak istediğiniz birçok çekirdek.

Git'i cmd'den kullanıyorsanız, Git Bash'ten çalıştırmayı deneyin. Cmd'de git.exe aslında her başlattığınızda doğru ortamı ayarlayan ve ancak sonra gerçek git.exe'yi başlatan bir sarmalayıcıdır. İstediğinizi yapmak için gereken sürenin iki katı kadar zaman alabilir. Git Bash, ortamı yalnızca başladığında kurar.

Yalnızca Aygıt Yöneticisi'nde AMD Radeon Graphics'i (veya Intel Graphics'i) kapatmak bana yardımcı oldu.

Cevabı burada buldum: /superuser/1160349/git-is-extremely-slow-on-windows# =

Birleşik cevaplar:

1. Wilbert's - PS1'e dahil edilecek bilgiler
2. sinelaw's - (<branch_name>)veya(<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}\] $ '

Sonuç:

Windows 7 x64'te Windows için Git'i (msysgit) bir süre sınırlı kullanıcı hesabı olarak çalıştırırken aynı sorunla karşılaştım.

Burada ve diğer yerlerde okuduğum kadarıyla, ortak tema idari ayrıcalıkların ve / veya UAC'nin eksikliği gibi görünüyor. Sistemimde UAC kapalı olduğundan, program dosyaları dizinine bir şeyler yazmaya / silmeye çalıştığı açıklaması bana en mantıklı geliyor.

Her durumda, Git 1.8'in taşınabilir sürümünü zipinstaller ile yükleyerek sorunumu çözdüm. Zipinstaller'ın çalışması için .7z dağıtım dosyasını açıp ZIP dosyası olarak yeniden paketlemem gerektiğini unutmayın. Ayrıca bu dizini sistem yoluma manuel olarak eklemek zorunda kaldım.

Performans şimdi iyi. Program Files (x86)Sınırlı bir kullanıcı için izinleri olmayan dizinde yüklü olsa da, aynı sorundan muzdarip görünmüyor.

Bunu, taşınabilir sürümün dosyaları yazdığı / sildiği, muhtemelen durumun biraz daha muhafazakâr olduğu ya da 1.7'den 1.8'e yükselttiği gerçeğine atfediyorum. Bash de dahil olmak üzere şu anda çok daha iyi çalıştığını söylemek için, hangisinin neden olduğunu tespit etmeye çalışmayacağım.

Benim durumumda, Git Bash'e yol açan Avast antivirüsüydü ve hatta PowerShell bile gerçekten yavaşlıyor.

İlk önce hızı artırıp iyileştirmediğini görmek için Avast'ı 10 dakika boyunca devre dışı bırakmayı denedim. Daha sonra, Git, Bash kurulum dizininin tamamını Avast'ta Okuma, Yazma ve Yürütme için bir istisna olarak ekledim. Benim durumumda C:\Program Files\Git\*.

Yukarıdakilerin hiçbiri bana yardım edemedi. Benim senaryomda sorun şu şekilde kendini gösteriyordu:

• Herhangi bir llkomut yavaştı (yürütülmesi yaklaşık 3 saniye sürüyordu)
• Herhangi bir sonraki llkomut anında yürütülür, ancak yalnızca önceki ls komutundan 45 saniye içinde olursa .

Process Monitor ile hata ayıklamaya gelince gelince, her komuttan önce bir DNS isteği olduğu tespit edildi.

Güvenlik duvarımı (benim durumumda Comodo) devre dışı bıraktığımda ve komutun sorunu çalıştırmasına izin vermez gitti. Güvenlik duvarı tekrar açıldığında geri dönmüyor. En erken fırsatta, bu yanıtı hangi işlemin DNS engelleme isteği yaptığını ve hedefin ne olduğunu daha ayrıntılı olarak güncelleyeceğim.

BR G

Benim durumumda Git Bash kısayolu olarak ayarlandı Start in:%HOMEDRIVE%%HOMEPATH%(Git Bash'ı sağ tıklayıp özellikleri seçerek bunu kontrol edebilirsiniz). Bu ağ sürücüsüdür.

Çözüm bunu göstermektir %HOME%. Elinizde yoksa, ortam değişkenlerinde ayarlayabilirsiniz ve şimdi Git Bash çok hızlı yanıp sönüyor olmalıdır.

Ben de git PS1 yavaşlığı ile ilgili sorun vardı, ancak uzun zamandır bir veritabanı boyutu sorunu (büyük depo) olduğunu düşünüyordum ve çeşitli git gchileler deniyordu ve tıpkı sizin gibi başka nedenler arıyorlardı. Ancak, benim durumumda, sorun bu satırdı:

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
}

Doing git statusher komut satırı durum satırında için yavaştı. Ahh. Elle yazdığım bir şeydi. Denediğimde bunun bir sorun olduğunu gördüm

export PS1='$'

burada bir cevapta bahsedildiği gibi. Komut satırı şimşek çakıyordu.

Şimdi bunu kullanıyorum:

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

Yığın taşması sonrası PS1 satırından git akım dal ve renkleri ile iyi çalışır. Yine hızlı bir Git komut satırı var.

Bir iş arkadaşım Windows (7) üzerinde Git'le ilgili sorun yaşadı git status checkoutve addhızlıydı, ancak git commityaşları aldı.

Hala bunun temel nedenini bulmaya çalışıyoruz, ancak havuzu yeni bir klasöre klonlamak sorunu düzeltti.

Birçoğunun dediği gibi, bunun nedeni stashWindows'ta bir kabuk komut dosyası olması, ancak Git 2.18.0'dan beri Windows yükleyicisinin daha hızlı (~% 90) yerleşik stash sürümünün deneysel bir özelliği için bir seçeneği var - https: / /github.com/git-for-windows/build-extra/pull/203 .