Git Bash é extremamente lento no Windows 7 x64

Eu tenho usado o Git no Windows e no Ubuntu durante o desenvolvimento de um projeto pequeno, alternando frequentemente entre os dois. A questão é que o Git Bash fica lento de forma consistente.

Quando digo devagar, quero dizer que a execução cdleva de 8 a 25 segundos, os gitcomandos de execução demoram de 5 a 20 segundos e lsàs vezes podem levar até 30 segundos. Escusado será dizer que isso não é divertido, para não mencionar improdutivo. Eu sei que o Git é mais lento no Windows, mas isso é ridículo.

A única solução que funcionou temporariamente para mim foi desativar minha conexão de rede (como sugerido nesta resposta ), iniciar o Git Bash e reconectar. Às vezes, continua a funcionar rapidamente por dias depois de fazer isso, mas o desempenho sempre diminui eventualmente. Pesquisei o grupo de discussão msysgit, Stack Overflow, lista de problemas do msysgit, etc. por semanas, mas não consegui encontrar soluções que funcionem.

Até agora, eu tentei:

• Adicionando pastas Git e projeto à lista de exclusão do antivírus
• Desativando meu antivírus completamente (Kaspersky IS 2011)
• Garantindo que o Outlook não esteja em execução (Outlook 2007)
• Desligando todos os outros aplicativos
• Executando o Git Bash como administrador
• Desabilitando a conexão de rede, iniciando o Git Bash e mantendo a conexão desabilitada
• Desativando a conexão de rede, iniciando o Git Bash, reativando a conexão (funciona apenas ocasionalmente)
• Corrida git gc
• E combinações dos itens acima

Eu li que algumas pessoas conseguiram desativar a conclusão do Bash, mas, idealmente, eu gostaria de manter isso ativo. A versão do msysgit é 1.7.3.1-preview20101002 e o sistema operacional é o Windows 7 x64. A execução das mesmas coisas no Linux é, previsivelmente, extremamente rápida. Eu usaria o Linux exclusivamente, mas também preciso executar coisas no Windows (certos aplicativos, testes etc.).

Alguém já encontrou um problema semelhante? Em caso afirmativo, qual era o problema subjacente e qual era a solução (se houver)?

Isso se estende além dos repositórios Git, mas apenas para referência, os repositórios com os quais tenho usado o Git são bem pequenos: ~ 4-50 arquivos no máximo.

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 realiza operações do sistema de arquivos em paralelo para ocultar a latência (atualização: habilitada 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: habilitada por padrão no Git for Windows 2.8)

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

Você tem informações do Git exibidas no prompt do Bash? Nesse caso, talvez você esteja inadvertidamente trabalhando demais em todos os comandos. Para testar essa teoria, tente a seguinte alteração temporária no Bash:

export PS1='$'

Meu diretório inicial do Windows está na rede e eu suspeitava que os comandos do Git Bash estivessem olhando primeiro. Com certeza, quando olhei $PATH, ele foi listado /h/binprimeiro, onde /hhá um compartilhamento em um servidor de arquivos do Windows, mesmo que /h/binnão exista.
Eu editei /etc/profilee comentei o comando de exportação que o coloca em primeiro lugar $PATH:

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

Isso fez com que meus comandos rodassem muito mais rápido, provavelmente porque o Git Bash não está mais procurando na rede os executáveis. Meu /etc/profilefoi c:\Program Files (x86)\Git\etc\profile.

Eu achei que a unidade de rede era o problema de desempenho. HOMEestava apontando para um compartilhamento de rede lento. Não pude substituir, HOMEDRIVEmas isso não é um problema do que vi.

Defina a variável de ambiente clicando com o botão direito do mouse na área de trabalho -> Propriedades -> Configurações avançadas do sistema -> Variáveis ​​de ambiente.

HOME=%USERPROFILE%

Em uma extensão da resposta de Chris Dolan, usei a seguinte PS1configuração alternativa . Basta adicionar o fragmento de código ao seu ~ / .profile (no 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\]
$ '

Isso mantém o benefício de um shell colorido e a exibição do nome atual da ramificação (se estiver em um repositório Git), mas é significativamente mais rápido na minha máquina, de ~ 0,75 sa 0,1 s.

Isso é baseado nesta postagem do blog .

Embora o seu problema possa ser baseado em rede, eu pessoalmente acelerei minhas git statuschamadas locais em dez vezes (mais de 7 segundos a 700 ms), fazendo duas modificações. Este está em um repositório de 700 MB com 21.000 arquivos e um número excessivo de arquivos binários grandes.

Um é ativar pré-carregamentos paralelos de índice. Em um prompt de comando:

git config core.preloadindex true
Isso mudou time git statusde 7 segundos para 2,5 segundos.

Atualizar!

O seguinte não é mais necessário. Um patch corrigiu isso no mysysgit 1.9.4
https://github.com/msysgit/git/commit/64d63240762df22e92b287b145d75a0d68a66988
No entanto, você deve ativar a correção digitando
git config core.fscache true

Também desabilitei o UAC e o driver "luafv" (é necessário reiniciar). Isso desativa um driver no Windows Vista, 7 e 8 que redireciona os programas que tentam gravar nos locais do sistema e, em vez disso, redireciona esses acessos para um diretório de usuários.

Para ver uma discussão sobre como isso afeta o desempenho do Git, leia aqui: https://code.google.com/p/msysgit/issues/detail?id=320

Para desativar esse driver, no regedit, altere a tecla "Iniciar" em HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/luafvpara 4 para desativar o driver. Em seguida, coloque o UAC na configuração mais baixa, "nunca notifique".

Se a desativação desse driver o deixar desconfiado (deveria), uma alternativa está sendo executada em uma unidade (ou partição) diferente da partição do sistema. Aparentemente, o driver é executado apenas no acesso a arquivos na partição do sistema. Eu tenho um segundo disco rígido e vejo resultados idênticos quando executado com esta modificação do registro na minha unidade C, como faço sem ela na unidade D.

Essa alteração leva time git statusde 2,5 segundos para 0,7 segundos.

Você também pode seguir https://github.com/msysgit/git/pull/94 e https://github.com/git/git/commit/d637d1b9a8fb765a8542e69bd2e04b3e229f663b para verificar quais trabalhos adicionais estão em andamento para problemas de velocidade no Windows .

Parece que desinstalar completamente o Git, reiniciar (a solução clássica do Windows) e reinstalar o Git foi a solução. Também limpei todos os arquivos de configuração do bash que sobraram (eles foram criados manualmente). Tudo está rápido novamente.

Se por algum motivo a reinstalação não for possível (ou desejável), eu definitivamente tentaria alterar a variável PS1 mencionada na resposta de Chris Dolan ; resultou em acelerações significativas em determinadas operações.

Resolvi meu problema lento do Git no Windows 7 x64 iniciando o cmd.exe com "Executar como administrador".

Vi uma melhoria decente ao configurar core.preloadindex como true, conforme recomendado aqui .

Como observado nas respostas de Chris Dolan e Wilbert, o PS1 deixa você mais lento .

Em vez de desativar completamente (como sugerido por Dolan) ou usar o script oferecido por Wilbert, eu uso um "PS1 burro" que é muito mais rápido.

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

No meu Cygwin, isso é mais rápido que a resposta "fast_Git_PS1" de Wilbert - 200 ms vs. 400 ms, portanto diminui um pouco sua rápida lentidão.

Não é tão sofisticado quanto __git_ps1- por exemplo, não altera o prompt quando você entra no diretório .git, etc., mas para o uso diário normal, é bom o suficiente e rápido.

Isso foi testado no Git 1.7.9 (Cygwin, mas deve funcionar em qualquer plataforma).

Você também pode obter um aumento de desempenho muito subseqüente alterando a seguinte configuração do Git:

git config --global status.submoduleSummary false

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

A ativação do 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

Eu estava tendo o mesmo problema, tanto no Git Bash quanto na GUI do Git. Ambos os programas costumam funcionar bem, mas então diminuem aleatoriamente para um rastreamento, e eu não conseguia descobrir o porquê.

Como se viu, era o Avast. O Avast fez com que coisas estranhas acontecessem com vários programas (incluindo programas que eu escrevi), então eu o desativei por um segundo e, com certeza, o Bash agora roda tão rápido quanto no Linux. Acabei de adicionar a pasta de arquivos de programa Git ( C:\Program Files\Git) à lista de exclusão do Avast e agora ela roda tão rápido quanto no Linux.

E sim, eu sei que o software antivírus não era o problema na postagem original, mas vou colocar isso aqui caso seja útil para alguém.

Além dessas outras respostas, acelerou projetos com vários submódulos usando a busca paralela por submódulos (desde o Git 2.8 no início de 2016).

Isso pode ser feito git fetch --recurse-submodules -j8e definido com git config --global submodule.fetchJobs 8, ou com quantos núcleos você tiver / deseja usar.

Se você usa o Git do cmd, tente executá-lo no Git Bash. No cmd, o git.exe é na verdade um invólucro que configura o ambiente correto toda vez que você o inicia e só então inicia o git.exe real. Pode levar até o dobro do tempo necessário para fazer o que você deseja. E o Git Bash configura o ambiente apenas quando é iniciado.

Somente desligar o AMD Radeon Graphics (ou Intel Graphics) no Gerenciador de dispositivos me ajudou.

Encontrei a resposta aqui: /superuser/1160349/git-is-extremely-slow-on-windows# =

Respostas combinadas:

1. Wilbert's - que informações incluir no PS1
2. sinelaw - (<branch_name>)ou(<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}\] $ '

Resultado:

Eu encontrei o mesmo problema ao executar o Git for 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 no meu sistema, a explicação de que ele está tentando gravar / excluir algo no diretório de arquivos do programa faz mais sentido para mim.

De qualquer forma, resolvi meu problema instalando a versão portátil do Git 1.8 com o zipinstaller. Observe que eu tive que descompactar o arquivo de distribuição .7z e reembalá-lo como um arquivo ZIP para que o zipinstaller funcionasse. Eu também tive que adicionar manualmente esse diretório ao caminho do sistema.

O desempenho está bom agora. Embora esteja instalado no Program Files (x86)diretório para o qual não tenho permissões como usuário limitado, ele não parece sofrer do mesmo problema.

Eu atribuo isso ao fato de que a versão portátil é um pouco mais conservadora no local em que grava / exclui arquivos, o que provavelmente é o caso, ou na atualização de 1.7 para 1.8. Não vou tentar identificar qual é o motivo, basta dizer que funciona muito melhor agora, incluindo o Bash.

No meu caso, na verdade, era o antivírus Avast levando o Git Bash e até o PowerShell a ficarem muito lentos.

Tentei desativar o Avast pela primeira vez por 10 minutos para ver se melhorava a velocidade. Depois, adicionei todo o diretório de instalação do Git Bash como uma exceção no Avast, para Leitura, Gravação e Execução. No meu caso, isso foi C:\Program Files\Git\*.

Nada do acima foi capaz de me ajudar. No meu cenário, o problema estava se mostrando assim:

• Qualquer llcomando estava lento (demorava cerca de 3 segundos para ser executado)
• Qualquer llcomando subseqüente foi executado instantaneamente, mas apenas se 45 segundos após o comando ls anterior .

Quando se tratava de depuração com o Process Monitor , verificou-se que antes de cada comando havia uma solicitação de DNS.

Então, assim que eu desabilitei meu firewall (Comodo no meu caso) e deixei o comando executar, o problema desapareceu. E ele não volta quando o firewall foi ligado novamente. Com a primeira oportunidade, atualizarei esta resposta com mais detalhes sobre o processo que estava executando uma solicitação de bloqueio de DNS e qual era o destino.

BR, G

No meu caso, o atalho do Git Bash foi definido como Start in:%HOMEDRIVE%%HOMEPATH%(você pode verificar isso clicando com o botão direito do mouse em Git Bash e selecionando propriedades). Esta foi a unidade de rede.

A solução é fazê-lo apontar %HOME%. Se você não o possui, pode configurá-lo nas variáveis ​​de ambiente e agora o Git Bash deve ser muito rápido.

Eu também tive problemas com a lentidão do git PS1, embora por muito tempo eu estivesse pensando que fosse um problema de tamanho de banco de dados (grande repositório) e tentasse vários git gctruques e procurasse outros motivos, como você. No entanto, no meu caso, o problema era esta linha:

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
}

A git statusexecução de todas as linhas de status da linha de comando era lenta. Ai. Foi algo que escrevi à mão. Vi que isso era um problema quando tentei o

export PS1='$'

como mencionado em uma resposta aqui. A linha de comando estava muito rápida.

Agora eu estou usando isso:

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

Na linha Stack Overflow pós PS1, com ramificação e cores atuais git , funciona bem. Novamente, tenha uma linha de comando rápida do Git.

Um colega de trabalho meu teve problemas com o Git no Windows (7) git status checkoute addfoi rápido, mas git commitlevou anos.

Ainda estamos tentando encontrar a causa raiz disso, mas a clonagem do repositório em uma nova pasta corrigiu o problema.

Como muitos disseram, isso se deve a stashum script de shell no Windows, mas desde o Git 2.18.0 o instalador do Windows tem uma opção para um recurso experimental de uma versão interna muito mais rápida (~ 90%) do stash - https: / /github.com/git-for-windows/build-extra/pull/203 .