Msysgit bash é terrivelmente lento no Windows 7


84

Eu amo o git e uso-o no OS X constantemente em casa. No trabalho, usamos svn no Windows, mas queremos migrar para git assim que as ferramentas estiverem totalmente amadurecidas (não apenas TortoiseGit , mas também algo parecido com a integração realmente agradável do Visual Studio fornecida pelo VisualSVN ). Mas estou divagando ...

Recentemente, instalei o msysgit em minha máquina com Windows 7 e, ao usar a versão incluída do bash, ele é terrivelmente lento. E não apenas as operações git; clearleva cerca de cinco segundos . AAAAH!

Alguém experimentou um problema semelhante?


Edit : Parece que o msysgit não está funcionando bem com o UAC e pode ser apenas um pequeno descuido de design resultante do desenvolvimento no XP ou da execução do Vista ou 7 com o UAC desabilitado; iniciar o Git Bash usando Run as administratorresultados na velocidade da luz que vejo no OS X (ou no 7 após iniciar o Git Bash sem uma conexão de rede - veja a resposta de @Gauthier).

Editar 2 : AH HA! Veja minha resposta.


Não 5 segundos lento, não. Será mais lento, mas mais rápido do que a versão Cygwin.
Yann Ramin de

@theatrus: Na verdade, usei um cronômetro agora. A média foi de 3,8 segundos. Então você está correto, mas algo ainda está profundamente errado.
Kevin L.

Outra lentidão do msysgit é uma versão antiga do OpenSSH documentada aqui darrell.mozingo.net/2011/09/29/…
JodaStephen


Respostas:


54

Você pode acelerar significativamente o Git no Windows executando três comandos para definir algumas opções de configuração:

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

Notas:

  • core.preloadindex faz operações do sistema de arquivos em paralelo para ocultar a latência (atualização: habilitado por padrão no git 2.1)

  • core.fscache corrige problemas de UAC para que você não precise executar o Git como administrador (atualização: habilitado por padrão no Git para Windows 2.8)

  • gc.auto minimiza o número de arquivos em .git /


Esta deve ser agora a resposta aceita. Funciona como um encanto!
krlmlr

8
Isso não funciona para mim. Meu git bash ainda tem um atraso de 1-2 segundos após eu dar um comando.
Jaskey

Caiu como uma luva para mim; reduzi meu status git em um grande repo de 13 segundos para 0,7 segundos
noelob

2
git config --global core.fscache truenão fez nada por mim; no entanto, git config core.fscache truefez o truque. De acordo com isso , é porque core.fscache é uma configuração por repo.
David Merriman

2
@DavidMerriman O comentário "por repo" está simplesmente afirmando que você pode alterar essa configuração em repositórios individuais. (O que é verdadeiro para todas as configurações, então não sei por que é mencionado.) O comentário não significa que funciona fscache apenas como uma configuração por repo. As configurações globais se aplicam a todos os repos em uma máquina, a menos que sejam substituídas por configurações por repo.
shoelzer

37

A solução para a lentidão no Vista ou 7 parece estar executando o Git Bash usando Run as administrator(ou desabilitando o UAC para o atalho do Git Bash ... ou desabilitando totalmente o UAC ). A diferença é noite e dia e usar o git no 7 é incrível novamente.

Isso parece estar relacionado a um problema conhecido e, como especulei, o XP como um ambiente de desenvolvimento para msysgit é parcialmente responsável.


Boa dica (mesmo que não seja intencional :)). Executar "git svn clone" no Windows 2008 R2 com 1.7.4 foi terrivelmente lento para mim (há mais de 5.000 commits no SVN e demorou semanas apenas para obter a metade) ... Você me deu a ideia de tentar em seu ambiente "nativo", no XP, e é realmente muito rápido. Obrigado!
bdrajer

1
Desativei o UAC e tentei executar como administrador, e ainda assim cada comando que insiro no Git Bash leva cerca de 5 segundos para ser executado (mesmo apenas lsem um diretório praticamente vazio)
Robin Winslow

4
A resposta a esta pergunta funcionou para mim em vez disso: stackoverflow.com/questions/4485059/…
Robin Winslow

Mover repositórios para uma partição fora do sistema também mostrou grandes aumentos de desempenho para minha equipe e evitou problemas aleatórios de "não foi possível criar arquivo" no checkout.
Laurence

1
Eu tentei várias soluções .. esta (rodando como administrador) finalmente funcionou para mim .. agora meu git é rápido como um raio mais uma vez .. obrigado .. :)
AweSIM

14

Para mim, o problema era usar __git_ps1 no prompt do shell - acho que devido ao acesso lento ao disco no msysgit.

A solução foi remover $ (__ git_ps1) das linhas PS1 = ... em / etc / profile

teste rápido se esta solução se aplica: em um shell git, digite export PS1 = '$' e verifique a velocidade de suas operações.


Obrigado! Este acabou sendo o meu problema no Windows XP. Consulte stackoverflow.com/q/5851611/200688
AndyL

2
Você provavelmente pode deixar __git_ps1ativo, se desativar as configurações SHOWDIRTYSTATE e / ou SHOWUNTRACKEDFILES, consulte stackoverflow.com/a/4203968/321973
Tobias Kienzler

Isso foi tudo que eu precisei no Windows 7. Particularmente sorte porque esta máquina está bloqueada sem privilégios de administrador!
ar em

12

Tentei quase todas as dicas aqui (incluindo a da minha outra resposta) em uma nova máquina, mas não funcionaram, o Git ainda estava lento como o diabo.

Depois, dei uma olhada no software virusscanning (que estava pré-instalado): desativei a varredura em tempo real do McAfee Security Center e pronto: o git está muito rápido agora! O tempo necessário para "git svn rebase" caiu de 30s para 5s (!).

Espero que isso seja útil para outras pessoas que ainda estão tendo problemas com a lentidão do Git no Windows, perdi horas tentando descobrir isso.


4
Meu Git Bash também começa lento antes, depois de adicionar todo o caminho de instalação do git ao caminho de exclusão do Avast! Anti-Virus Suite, git bash começa abaixo de 0,5s
zhxchen17

Essa foi a resposta para mim !! Eu uso o AVG Free. Eu apenas desativei por 10 minutos, de repente o bash veeerrryyyy lento é rápido como um raio.
Mörre

Para aqueles que usam o Windows Defender, você pode fazer com que ele exclua uma pasta ou processo. Consulte support.microsoft.com/en-us/help/4028485/…
Ehtesh Choudhury

9

Infelizmente, 'Executar como Administrador' não funcionou para mim - mas, como Kevin L descobriu, desconectar o adaptador de rede, iniciar git bash e reconectar funcionou bem. Então, eu envolvi isso em um script em lote e coloquei um atalho para ele no meu menu Iniciar, sinalizado para ser executado como administrador:

netsh interface set interface "Local Area Connection" DISABLED
cd "%USERPROFILE%\Documents\Visual Studio 2010\Projects"
start cmd /c ""C:\Program Files\Git\bin\sh.exe" --login -i"
netsh interface set interface "Local Area Connection" ENABLED

Funciona muito bem, desde que eu me lembre de que minha rede é interrompida momentaneamente.

(Win 7 Professional SP1, Git versão 1.7.8-preview20111206)


5

Um colega meu tinha esse comportamento sempre que o Outlook estava em execução. Tentando matar o outlook e testar novamente.

Você também pode tentar testar:

  • sem conexão com qualquer rede,
  • sem antivírus em execução,
  • sem qualquer outro programa em execução.

3
Nem o Outlook nem o antivírus parecem ter qualquer efeito, mas se eu desabilitar minha conexão de rede e iniciar o git, ele será rápido (leia: "Unix"), mesmo depois de me reconectar. Interessante ...
Kevin L.

Sim. E o git bash continua rápido (até que eu feche e abra outra instância).
Kevin L.

2
A conexão de rede também funcionou para mim. Eu me pergunto o que isso tem a ver com conexão de rede. E estranhamente funciona perfeitamente bem na minha rede doméstica, mas se recusa a funcionar na rede do meu escritório.
Sarath de

Isso corrigiu meu problema no Windows 7 Professional de 64 bits em um iMac totalmente novo. Felicidades!
longda de

Um antivírus como sugerido foi a causa em meu sistema específico. windows 7 x64 ultimate. Infelizmente, o UAC (mencionado em outro lugar) não fez diferença. Obrigado a todos
MickyD

3

Descobrimos que, ao ser executado em certas contas de usuário, instâncias separadas do git.exe são bloqueadas em uma chamada para WaitForSingleObject(), portanto, apenas uma única operação do git.exe pode ser executada de uma vez. Alterar a conta do usuário contornou esse problema.

Detalhes aqui: https://stackoverflow.com/a/13054022


3

Eu tenho MacAffee e dizer a ele para excluir o diretório .git e todos os subdiretórios da verificação em tempo real resolveu o problema de desempenho.


1
Você pode excluir todo o disco rígido? ;-).
Peter - Reintegrar Monica de

1

Conforme encontrado neste problema , executar com a virtualização do UAC desligada (não é necessário desabilitar totalmente o UAC) faz uma grande diferença.

Esta postagem explica como desligá-lo (veja no final da postagem, apenas uma configuração de registro).

Em um (grande) repo SVN ao qual estou me conectando, fazer apenas a alteração acima diminuiu o tempo necessário para "git svn rebase" de 15s para 5s, uma melhoria de fator 3.


Este problema (rastreador) foi fechado, o novo problema relacionado a ele é: github.com/msysgit/git/issues/94
childno͡.de

1

Uma alternativa para mexer com o UAC do Windows 7 pode ser instalar o mysysgit fora da pasta Arquivos de programas. Por exemplo, em vez de "C: \ Arquivos de programas (x86) \ Git", tente instalar em "C: \ git"

Tentei mexer em 'Executar como administrador' e nos controles do UAC sem sucesso, mas desisti e comecei uma nova instalação. Eu estava recebendo cerca de 15 KiB / s no máximo antes, mas agora está acima de 60kiB / s.


1

Se desligar o UAC não melhorar o desempenho, tente desligar o driver luafv. Isso funcionou para mim depois de tentar quase tudo nesta página e algumas perguntas semelhantes. O Git passou de excepcionalmente lento para bastante decente.

Abra 'regedit' e encontre a chave de registro

HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services/luafv

Altere o valor de Start2 para 4.

Encontrei os detalhes sobre como desabilitar luafv aqui . Observe que eu pessoalmente não tenho ideia do que luafvé ou faz. Essa página fornece vários avisos sobre coisas ruins que podem acontecer se você desligá-lo, o que você provavelmente deve levar a sério.

EDIT: O comentário abaixo apontou que entendi errado (o link mostra da maneira certa). Está consertado agora. Desculpe às pessoas cujos registros eu destruí :)


O meu é definido como 2 por padrão. Ainda bem lento.
imanuelcostigan

@imanuelc: ironicamente, o meu também está agora (em um novo computador) e também está lento.
jwg

2
Isso está incorreto. Deve ser alterado de 2 para 4. 2 significa inicialização automática. 4 significa desativado.
richb de

1

Estou solucionando isso há algum tempo e tive dificuldade em localizar a origem do problema. No final, descobri duas coisas que tiveram um impacto dramático:

  • Desligando o serviço Windows Search. Isso teve um efeito dramático no desempenho.
  • Fechando extensões Git. Ter a janela Git Extensions Browse aberta em segundo plano fez com que os tempos de execução do comando Cygwin git aumentassem em um fator aparentemente aleatório de até cerca de 10.

0

O problema aqui pode ser a conclusão do bash se estiver habilitada, que é um pouco mais lenta no Windows do que no Linux.

Tente definir a variável PS1 para algo simples como "$" e veja se isso acelera as coisas. Em caso afirmativo, esteja ciente de que houve algumas otimizações na conclusão do bash nas versões recentes do git. Talvez você precise atualizar.


1
Estou executando a versão mais recente absolutamente inovadora (veja meus comentários sobre a resposta de VonC, acima). Mas vou tentar.
Kevin L.

1.7.0.2 não é necessariamente o que há de mais moderno neste contexto. As otimizações de que estou falando aconteceram no upstream-git. Não tenho certeza se eles participaram do lançamento 1.7.0.2 do Git para Windows ou não.
kusma

0

Isso funcionou para mim. Não espere que seja uma solução única para todos.

Verifique a variável de ambiente $ HOME no bash e no windows. Se apontar para uma conta de usuário, verifique o perfil / permissões do Windows do usuário. Altere a conta do usuário ou $ HOME de acordo.


6
Poderia falar um pouco mais sobre esses perfis / permissões nefastos?
Tobias Kienzler

0

Eu encontrei o mesmo problema ao executar git para Windows (msysgit) no Windows 7 x64 como uma conta de usuário limitada por algum tempo. Pelo que li aqui e em outros lugares, o tema comum parece ser a falta de privilégios administrativos e / ou UAC. Como o UAC está desativado em meu sistema, a explicação de que ele está tentando gravar / excluir algo no diretório de arquivos de programa faz mais sentido para mim.

Em qualquer caso, resolvi meu problema instalando a versão portátil do git 1.8 com zipinstaller. Observe que eu tive que descompactar o arquivo de distribuição .7z e reembalá-lo como um zip para que o zipinstaller funcione. Também tive que adicionar manualmente esse diretório ao caminho do meu sistema.

O desempenho está bom agora. Embora esteja instalado no diretório Arquivos de Programas (x86), para o qual não tenho permissão como usuário limitado, não parece ter o mesmo problema. Atribuo isso ao fato de que a versão portátil é um pouco mais conservadora em onde grava / exclui arquivos, o que provavelmente é o caso, ou à atualização de 1.7 para 1.8. Não vou tentar definir qual é o motivo, basta dizer que funciona muito melhor agora.


0

Você pode querer tentar desinstalar o msysgit, reiniciar o Windows, instalar a última versão do msysgit. Pareceu funcionar para mim. Encontrei esta sugestão aqui:

https://stackoverflow.com/a/4506192/1413941

EDITAR

PS Eu já tinha desabilitado o UAC antes de encontrar problemas lentos com o Git, então não sei se desabilitar o UAC é necessário ou não para fazer o Git funcionar mais rápido.


0

A melhor solução é executar como administrador, conforme apontado. No entanto, outra opção para tornar o status git rápido, pelo menos, é trustctime = false . Antes disso, o status do git levava cerca de 30 segundos e depois disso é a mesma quantidade que é mostrada na saída - levou X segundos para ...


0

Você também pode obter um importante aumento de desempenho alterando a seguinte configuração git:

git config --global status.submoduleSummary false

Ao executar o git statuscomando simples no Windows 7 x64, meu computador levou mais de 30 segundos para ser executado. Depois que essa opção for definida, o comando é imediato.

Ativar o próprio rastreio do Git conforme explicado na página a seguir me ajudou a encontrar a origem do problema, que pode ser diferente em sua instalação: https://github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is-so- lento


-4

Provavelmente é uma questão de prompt que analisa seu repositório Git. Você pode testar fazendo "clear" em algum lugar fora de um repositório Git. E você pode acelerá-lo corrigindo git-completed.bash ou fazendo truques com core.filemode.

Quanto à integração do Visual Studio: Este é Open Source. É injusto esperar que outros trabalhem para você de graça.

Também acho bastante engraçado não fazer a pergunta na lista de e-mails msysGit, mas agora estou divagando.


5
Flaming em StackOverflow não deve ser tolerado. Por favor, tente manter o discurso mais civilizado
phord

1
É engraçado. Meu comentário foi o único comentário com informações técnicas concretas. A oferta para ajudar a resolver o problema ainda está aberta, sabe? E, claro, estou bastante chateado que o problema foi levantado aqui, no stackoverflow, que eu não monitoro e que teve que ser apontado por outros para mim. Eu teria preferido ouvir sobre o problema diretamente. Não sei quanto a você, mas acho injusto quando o projeto original nem sequer é notificado dos problemas.
Dscho

Dois anos depois, eu concordo. Eu fui muito duro. Desculpe, Dscho. As listas de discussão do desenvolvedor git são realmente úteis.
phord

2
@Dscho, você deve entender que as pessoas costumam postar aqui primeiro porque querem verificar se não há algum problema de configuração ou plataforma, o que não é um bug no Git, causando o problema.
jwg
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.