Git Bash è estremamente lento su Windows 7 x64

Ho usato Git su Windows e Ubuntu durante lo sviluppo di un piccolo progetto, girando spesso avanti e indietro tra i due. Il problema è che Git Bash diventa costantemente lento.

Quando dico lento, intendo che la corsa cdimpiega da 8 a 25 secondi, i gitcomandi di corsa impiegano da 5 a 20 secondi e lstalvolta possono richiedere fino a 30 secondi. Inutile dire che non è divertente, per non dire improduttivo. So che Git è più lento su Windows, ma questo è ridicolo.

L'unica soluzione che ha funzionato - temporaneamente - per me è stata quella di disabilitare la mia connessione di rete (come suggerito in questa risposta ), avviare Git Bash e quindi riconnettersi. A volte continua a funzionare rapidamente per giorni dopo averlo fatto, ma alla fine le prestazioni peggiorano sempre. Ho esplorato il gruppo di discussione msysgit, StackTranslate.it, elenco dei problemi di msysgit, ecc. Da settimane, ma non sono riuscito a trovare soluzioni che funzionino.

Finora ho provato:

• Aggiunta di cartelle Git e progetti all'elenco di esclusione dello scanner antivirus
• Disabilitazione completa del mio antivirus (Kaspersky IS 2011)
• Assicurarsi che Outlook non sia in esecuzione (Outlook 2007)
• Chiudere tutte le altre applicazioni
• Esecuzione di Git Bash come amministratore
• Disabilitare la connessione di rete, avviare Git Bash e mantenere disabilitata la connessione
• Disabilitazione della connessione di rete, avvio di Git Bash, riattivazione della connessione (funziona solo occasionalmente)
• In esecuzione git gc
• E combinazioni di quanto sopra

Ho letto che un paio di persone hanno avuto successo disabilitando il completamento di Bash, ma idealmente mi piacerebbe mantenerlo attivo. La versione di msysgit è 1.7.3.1-preview20101002 e il sistema operativo è Windows 7 x64. Eseguire le stesse cose su Linux è, prevedibilmente, velocissimo. Vorrei usare esclusivamente Linux, ma ho bisogno di eseguire roba anche su Windows (alcune applicazioni, test, ecc.).

Qualcuno ha riscontrato un problema simile? In tal caso, qual è stato il problema di fondo e qual è stata la soluzione (se presente)?

Questo si estende oltre ai soli repository Git, ma solo per riferimento, i repository con cui ho utilizzato Git sono stati piuttosto piccoli: ~ 4-50 file al massimo.

Puoi velocizzare significativamente Git su Windows eseguendo tre comandi per impostare alcune opzioni di configurazione:

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

Appunti:

• core.preloadindex esegue le operazioni del filesystem in parallelo per nascondere la latenza (aggiornamento: abilitato per impostazione predefinita in Git 2.1)

• core.fscache risolve i problemi di controllo dell'account utente in modo da non dover eseguire Git come amministratore (aggiornamento: abilitato per impostazione predefinita in Git per Windows 2.8)

• gc.auto minimizza il numero di file in .git /

Hai informazioni Git visualizzate nel tuo prompt di Bash? Se è così, forse stai inavvertitamente facendo troppo lavoro su ogni comando. Per testare questa teoria prova la seguente modifica temporanea in Bash:

export PS1='$'

La mia home directory di Windows è sulla rete e sospettavo che i comandi di Git Bash stessero cercando lì per primi. Abbastanza sicuro, quando ho guardato $PATH, è elencato per /h/binprimo, dove si /htrova una condivisione su un file server Windows, anche se /h/binnon esiste.
Ho modificato /etc/profilee commentato il comando export che lo inserisce per primo in $PATH:

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

Questo ha reso i miei comandi molto più veloci, probabilmente perché Git Bash non sta più cercando gli eseguibili attraverso la rete. Il mio /etc/profileera c:\Program Files (x86)\Git\etc\profile.

Ho scoperto che l'unità di rete era il problema delle prestazioni. HOMEstava indicando una condivisione di rete lenta. Non ho potuto ignorare, HOMEDRIVEma questo non è un problema da quello che ho visto.

Imposta la variabile d'ambiente facendo clic con il tasto destro del mouse sul desktop -> proprietà -> Impostazioni di sistema avanzate -> Variabili d'ambiente Aggiungi alla sezione Variabili utente

HOME=%USERPROFILE%

In un'estensione della risposta di Chris Dolan, ho usato la seguente PS1impostazione alternativa . Aggiungi semplicemente il frammento di codice al tuo ~ / .profile (su 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\]
$ '

Ciò mantiene il vantaggio di una shell colorata e della visualizzazione del nome del ramo corrente (se in un repository Git), ma è significativamente più veloce sulla mia macchina, da ~ 0,75 sa 0,1 s.

Questo si basa su questo post del blog .

Mentre il tuo problema potrebbe essere basato sulla rete, ho personalmente accelerato di git statusdieci volte le mie chiamate locali (da 7+ secondi a 700 ms) apportando due modifiche. Questo è su un repository da 700 MB con 21.000 file e un numero eccessivo di file binari di grandi dimensioni.

Uno è abilitare i precarichi di indice parallelo. Da un prompt dei comandi:

git config core.preloadindex true
Questo è cambiato time git statusda 7 secondi a 2,5 secondi.

Aggiornare!

Non è più necessario quanto segue. Una patch ha risolto questo problema da mysysgit 1.9.4
https://github.com/msysgit/git/commit/64d63240762df22e92b287b145d75a0d68a66988
Tuttavia, è necessario abilitare la correzione digitando
git config core.fscache true

Ho anche disabilitato l'UAC e il driver "luafv" (riavvio richiesto). Ciò disabilita un driver in Windows Vista, 7 e 8 che reindirizza i programmi che tentano di scrivere nelle posizioni di sistema e reindirizza invece gli accessi a una directory utente.

Per una discussione su come ciò influisce sulle prestazioni di Git, leggi qui: https://code.google.com/p/msysgit/issues/detail?id=320

Per disabilitare questo driver, in regedit, cambiare il tasto "start" su HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/luafv4 per disabilitare il driver. Quindi, imposta UAC sulla sua impostazione più bassa, "non avvisare mai".

Se la disabilitazione di questo driver ti rende diffidente (dovrebbe), un'alternativa è in esecuzione su un'unità (o partizione) diversa dalla partizione di sistema. Apparentemente il driver funziona solo sull'accesso ai file sulla partizione di sistema. Ho un secondo disco rigido e vedo risultati identici quando eseguito con questa modifica del registro sul mio disco C come faccio senza di esso sul disco D.

Questa modifica richiede time git statusda 2,5 secondi a 0,7 secondi.

Potresti anche voler seguire https://github.com/msysgit/git/pull/94 e https://github.com/git/git/commit/d637d1b9a8fb765a8542e69bd2e04b3e229f663b per verificare quali lavori aggiuntivi sono in corso per problemi di velocità in Windows .

Sembra che la cura sia stata disinstallare completamente Git, riavviare (la classica cura di Windows) e reinstallare Git. Ho anche cancellato tutti i file di configurazione di bash che erano rimasti (sono stati creati manualmente). Tutto è di nuovo veloce.

Se per qualche motivo la reinstallazione non fosse possibile (o desiderabile), allora proverei sicuramente a cambiare la variabile PS1 a cui fa riferimento la risposta di Chris Dolan ; ha comportato accelerazioni significative in alcune operazioni.

Ho risolto il mio lento problema Git su Windows 7 x64 avviando cmd.exe con "Esegui come amministratore".

Ho visto un miglioramento decente impostando core.preloadindex su true come raccomandato qui .

Come notato nelle risposte di Chris Dolan e Wilbert, PS1 ti rallenta .

Invece di disabilitare completamente (come suggerito da Dolan) o usare lo script offerto da Wilbert, uso una "stupida PS1" che è molto più veloce.

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

Sul mio Cygwin, questo è più veloce della risposta "fast_Git_PS1" di Wilbert - 200 ms contro 400 ms, quindi si elimina un po 'della tua lentezza.

Non è così sofisticato come __git_ps1- ad esempio non cambia il prompt quando si esegue il cd nella directory .git, ecc. Ma per il normale uso quotidiano è abbastanza buono e veloce.

Questo è stato testato su Git 1.7.9 (Cygwin, ma dovrebbe funzionare su qualsiasi piattaforma).

Potresti anche ottenere un aumento delle prestazioni molto subsquent modificando la seguente configurazione Git:

git config --global status.submoduleSummary false

Quando eseguo il semplice git statuscomando su Windows 7 x64, il mio computer ha impiegato più di 30 secondi per essere eseguito. Dopo aver definito questa opzione, il comando è immediato.

L'attivazione della traccia di Git come spiegato nella pagina seguente mi ha aiutato a trovare l'origine del problema, che potrebbe differire nella tua installazione: https://github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is-so- lento

Stavo avendo lo stesso problema, sia in Git Bash che in Git GUI. Entrambi i programmi funzionano bene, ma poi hanno rallentato casualmente a passo d'uomo, e non sono riuscito a capire perché.

A quanto pare, era Avast. Avast ha fatto accadere cose strane a vari programmi (compresi i programmi che scrivo), quindi l'ho disabilitato per un secondo, e sicuramente abbastanza, Bash ora funziona più veloce che su Linux. Ho appena aggiunto la cartella dei file di programma Git ( C:\Program Files\Git) all'elenco di esclusione di Avast e ora funziona velocemente come su Linux.

E sì, mi rendo conto che il software antivirus non era il problema nel post originale, ma lo inserirò qui nel caso sia utile a qualcuno.

Oltre a queste altre risposte, ho velocizzato i progetti con più sottomoduli usando il recupero parallelo dei sottomoduli (da Git 2.8 all'inizio del 2016).

Questo può essere fatto con git fetch --recurse-submodules -j8e impostato con git config --global submodule.fetchJobs 8, o comunque molti core che hai / vuoi usare.

Se usi Git da cmd, prova a eseguirlo da Git Bash. In cmd, git.exe è in realtà un wrapper che configura l'ambiente corretto ogni volta che lo avvii e solo allora avvia il vero git.exe. Può richiedere fino al doppio del tempo necessario per fare solo quello che vuoi. E Git Bash imposta l'ambiente solo all'avvio.

Mi ha aiutato solo a disattivare AMD Radeon Graphics (o Intel Graphics) in Gestione dispositivi.

Ho trovato la risposta qui: /superuser/1160349/git-is-extremely-slow-on-windows# =

Risposte combinate:

1. Wilbert - quali informazioni includere in PS1
2. sinelaw's - (<branch_name>)o(<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}\] $ '

Risultato:

Ho riscontrato lo stesso problema con Git per Windows (msysgit) su Windows 7 x64 come account utente limitato per un po 'di tempo.

Da quello che ho letto qui e in altri luoghi, il tema comune sembra essere la mancanza di privilegi amministrativi e / o UAC. Dal momento che UAC è disattivato sul mio sistema, la spiegazione che sta cercando di scrivere / eliminare qualcosa nella directory dei file di programma ha più senso per me.

In ogni caso, ho risolto il mio problema installando la versione portatile di Git 1.8 con zipinstaller. Nota che ho dovuto decomprimere il file di distribuzione .7z e reimballarlo come file ZIP per far funzionare zipinstaller. Ho anche dovuto aggiungere manualmente quella directory al mio percorso di sistema.

Le prestazioni ora vanno bene. Anche se è installato nella Program Files (x86)directory, per la quale non ho i permessi come utente limitato, non sembra soffrire dello stesso problema.

Lo attribuisco sia al fatto che la versione portatile è un po 'più conservativa in cui scrive / elimina i file, che è probabilmente il caso, sia all'aggiornamento da 1.7 a 1.8. Non cercherò di individuare quale sia il motivo, basti dire che ora funziona molto meglio, incluso Bash.

Nel mio caso, in realtà era l'antivirus Avast che ha portato Git Bash e persino PowerShell a diventare molto lenti.

Ho provato a disabilitare Avast per 10 minuti per vedere se migliorava la velocità e lo ha fatto. Successivamente, ho aggiunto l'intera directory di installazione di Git Bash come eccezione in Avast, per Read, Write ed Execute. Nel mio caso lo era C:\Program Files\Git\*.

Nulla di quanto sopra è stato in grado di aiutarmi. Nel mio scenario il problema si stava mostrando in questo modo:

• Qualunque ll comando era lento (l'esecuzione di circa 3 secondi)
• Qualsiasi llcomando successivo veniva eseguito all'istante, ma solo se entro 45 secondi dal precedente comando ls .

Quando si è trattato di debug con Process Monitor, è stato riscontrato che prima di ogni comando c'era una richiesta DNS.

Quindi non appena ho disabilitato il mio firewall (Comodo nel mio caso) e ho lasciato che il comando eseguisse il problema è sparito. E non ritorna quando il firewall è stato riacceso. Con la prima opportunità aggiornerò questa risposta con maggiori dettagli su quale processo stava facendo una richiesta DNS bloccante e quale fosse l'obiettivo.

BR, G

Nel mio caso, il collegamento Git Bash era impostato su Start in:%HOMEDRIVE%%HOMEPATH%(puoi verificarlo facendo clic con il tasto destro su Git Bash e selezionando le proprietà). Questa era l'unità di rete.

La soluzione è farla puntare %HOME%. Se non lo hai, puoi impostarlo nelle variabili di ambiente e ora Git Bash dovrebbe essere velocissimo.

Ho anche avuto problemi con la lentezza di Git PS1, anche se per molto tempo ho pensato che fosse un problema di dimensioni del database (grande repository) e stavo provando vari git gctrucchi e stavo cercando altri motivi, proprio come te. Tuttavia, nel mio caso, il problema era questa riga:

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
}

Fare git statusper ogni riga di stato della riga di comando era lento. Ahia. Era qualcosa che ho scritto a mano. Ho visto che era un problema quando ho provato

export PS1='$'

come menzionato in una risposta qui. La riga di comando era velocissima.

Ora sto usando questo:

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

Dallo Stack Overflow inserisci la linea PS1 con git corrente ramo e colori e funziona benissimo. Ancora una volta hai una riga di comando Git veloce.

Un mio collega ha avuto problemi con Git su Windows (7) git status checkouted è addstato veloce, ma ha git commitimpiegato anni.

Stiamo ancora cercando di trovare la causa principale, ma la clonazione del repository in una nuova cartella ha risolto il suo problema.

Come molti hanno detto, questo è dovuto allo stashscript di shell su Windows, ma a partire da Git 2.18.0 il programma di installazione di Windows ha un'opzione per una funzionalità sperimentale di una versione incorporata molto più veloce (~ 90%) di stash - https: / /github.com/git-for-windows/build-extra/pull/203 .