Git Bash é extremamente lento no Windows 7 x64

434

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.

Gêmeos14
fonte
1
Para não desencorajar você, mas o Cygwin é muito lento no x64, é melhor experimentá-lo no Windows XP 32bit.
Ismail
2
possível duplicata de msysgit bash é terrivelmente lento no Windows 7
childno͡.de
5
No mesmo sistema, não demorou meio ano atrás. Eles devem ter mudado alguma coisa ...
Tomáš Zato - Restabelece Monica
2
Em praticamente todas as máquinas aqui: o Kaspersky AV diminui bastante o git e "desabilitar" o Kaspersky está quebrado, o avp.exe ainda é executado depois de sair completamente. A reinstalação completa do Kaspersky geralmente corrige o último problema.
Peterchen
2
Veja a página wiki do msysgit nisto: github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is-so-slow
Drew Noakes

Respostas:

409

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 /

sapatilha
fonte
Não me ajudou, mas ajudou a exportação PS1 = '$' mencionada abaixo. Então eu sei que o problema é a linha terminal.
Koshmaar
67
Configurações completamente inúteis em 2017 (git 2.12) porque todo esse material está ativado por padrão. Mas o git ainda funciona lentamente como uma merda.
ieXcept
2
Funciona muito bem no Windows 10 também. Bem feito e obrigado por este @shoelzer!
Joe
1
Limitar os arquivos a 256 pode causar alguns problemas. E as duas primeiras opções já ativadas em novas versões do git.
NPcomp
@sonyvizio Que tipo de problemas?
Shoelzer 17/05/19
102

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='$'
Chris Dolan
fonte
11
O problema é com $(__git_ps1)... querer retirar esta faz tudo super
Hendy Irawan
10
Para os não iniciados entre nós, o que exatamente esse comando faz? Você diz que é "temporário", como revertemos o comando?
Immortal Blue
5
Também corrigi meus problemas de desempenho. Para corrigir permanentemente, edite C:\Program Files (x86\Git\etc\profilee comente o if-then-else onde __git_ps1é adicionado PS1.
Tom
6
Na versão atual 2.18.0, não consigo encontrar o comando __git_ps1 em / etc / profile. Ele se mudou para outro lugar?
keinabel
8
Parece ter sido movido para C: \ Arquivos de Programas \ Git \ etc \ profile.d \ git-prompt.sh. Eu comentei __git_ps1 neste arquivo e ele foi muito mais rápido (mas perdeu informações filial no prompt)
Miyagi
85

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.

Rob Johnson
fonte
6
Eu tive o mesmo problema. Mudei HOME="$(cd "$HOME" ; pwd)"para HOME="$(cd "$USERPROFILE" ; pwd)"e agora tudo é incrivelmente rápido. Obrigado pela dica.
Jon Sagara
2
Fui bem-sucedido ao usar uma variação disso: no perfil, force $ HOME a $ USERPROFILE, removendo a referência $ HOMEDRIVE. Também nas propriedades do atalho do Git Bash, defina "Start In" como% USERPROFILE%
Aidan Ryan
11
Isso corrigiu meu problema na maior parte do tempo, mas com o Git pelo menos a partir da versão 2.7.2, descobri que exportar no /etc/profile.d/env.sh em vez de diretamente no arquivo / etc / profile.
Jared Siirila 29/03
15
Muito obrigado, mesmo problema para mim, no entanto, eu o corrigi criando uma variável de ambiente (usuário) chamada HOME, apontando para o diretório inicial desejado. Se $ HOME não estiver presente, aparentemente o git bash será padronizado como% USERPROFILE%. Depois disso, o git bash é super rápido.
JHH 14/04
6
A única opção que funcionou foi a @JHH descrita nos comentários. Adicione uma variável de ambiente de usuário do Windows chamada HOME e defina o diretório inicial desejado. (Painel de Controle -> Sistema -> Configurações avançadas do sistema -> Variáveis de Ambiente)
RenRen
45

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%
MichaelK
fonte
4
Isso funcionou. Para todos que têm o problema de rede, esta é a solução real. Você não precisa editar nenhum arquivo de configuração, apenas faça o HOME apontar para onde deveria.
Carlos Calla
1
Definir Var de Usuário Env HOME como% USERPROFILE% não funcionou. I definido SISTEMA VAR: HOME = C: \ Users \ myusername
colin_froggatt
Trabalhou para mim! Obrigado. Eu fiz algo como @colin_froggatt mas em variáveis de ambiente de utilizador em vez disso, definindo HOME = C: \ Users \ myusername
D ..
22

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 .

Wilbert
fonte
Ótima resposta. No entanto, decidi redefinir '__git_ps1 ()' no meu ~ / .bashrc e apenas imprimir uma string vazia. Acelera todos os comandos do Bash.
ajukraine
Sou iniciante no git, gostaria de saber qual é a diferença entre este fast_git_ps1 e o __git_ps1 original bastante complicado. Tenho a ideia de que isso funcionará para a maioria dos casos "normais", mas o que é normal e onde isso falhará?
sundar - Restabelece Monica
Não conheço casos em que isso falhará. Eu usei o __git_ps1 antes, mas notei os problemas de desempenho, então tentei fazer com que o git fizesse menos trabalho para extrair as informações exibidas.
Wilbert
2
O original __git_ps1inclui informações de status, não apenas o nome da filial. Por exemplo, se você estiver em um estado de cabeça desanexada, no dir git, em um repositório vazio, no meio da escolha da cereja ou rebasing ou mesclagem ... Isso será mais rápido, mas poderá haver ocasiões em que você perderá essa informação extra, especialmente como iniciante no Git.
Drew Noakes
22

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 .

Jeff Lamb
fonte
10
isso apenas esclarece, mais uma vez, soluções idiotas e sinuosas da Microsoft, para os problemas resolvidos no Unix de maneira simples e elegante em 1968. Quanto esforço de produção, tempo e dinheiro foram desperdiçados pelo inchaço da Microsoft e pela falta de refatoração / flexibilidade / audácia em todo o mundo?
v.oddou
20
Lembro-me de usar o git em 68, foi glorioso.
Charlie Brown
2
Haha um ano antes de Linus veio ao redor @CharlieBrown
cchamberlain
1
ativado por padrão no git 2.1 stackoverflow.com/a/24045966/4854931
Alex78191
18

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.

Gêmeos14
fonte
3
Reinstalar sem reiniciar não funcionou, desinstalar-reiniciar-instalar funcionou. Obrigado! Seria bom saber por que e como o bash ficou tão lento.
Gauthier 5/05
A reinstalação com a reinicialização intermediária não fez diferença para mim.
RyanW
@RyanW Acho que não posso ajudar além da solução acima que funcionou para mim, mas como esse problema ainda não parece estar resolvido permanentemente, convém entrar em contato com os mantenedores do msysgit e ver se eles conseguem descobrir. a causa desse problema.
precisa saber é o seguinte
3
Quais arquivos de configuração do bash você eliminou exatamente?
Scott
3
Esta não é a solução para a resposta. Quando você desinstalou e reinstalou algum arquivo de configuração pode ter sido alterado, essas alterações são a resposta. Se você disser apenas que reinstalar é a solução, está errado. Outras pessoas podem desinstalar e reinstalar e os arquivos de configuração podem ser os mesmos e é por isso que não funciona para todos.
Carlos Calla
10

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

Chris Pawlukowsky
fonte
10
A pergunta fala sobre o git bash.
manojlds
2
Você pode executar o git bash como administrador; que pode parecer indicar um problema UAC
krosenvold
3
Uau, melhoria enorme velocidade rodando o bash git como administrador
Evil E
Não sei por que essa resposta tem apenas 6 votos positivos. Eu acho que essa resposta resolveu o problema completamente. Há uma enorme melhoria de velocidade.
vinoth10
2
@ vinoth10 Bem, existe o problema de, você sabe, rodar como administrador. O que por muitas razões é uma má ideia e, para muitos casos de uso corporativos, não é uma opção. Resolver um problema de desempenho elevando o usuário é uma solução horrível.
JHH
6

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

sinelaw
fonte
Você também pode usar a --shortopção para não imprimirrefs/heads/
friederbluemle
@friederbluemle, qual versão do git você está usando? O meu (1.7.9) não oferece --shorto symbolic-refcomando.
sinelaw
Atualizado para não imprimir erros quando fora de qualquer repo git, e trabalhar para cabeças separadas
sinelaw
Eu estou usando 1.8.4 (msysgit)
friederbluemle
6

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

Olivier
fonte
5

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.

Nkosi Dean
fonte
4

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.

codehearts
fonte
2

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.

Eugene Pakhomov
fonte
2

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:

Você está em: Página Inicial> Imprensa> Notícias> Notícias

rofrol
fonte
não torná-lo mais rápido
keinabel
@keinabel Neste momento eu olharia core.commitGraph=truede blogs.msdn.microsoft.com/devops/2018/06/25/... e outro de blogs.msdn.microsoft.com/devops/tag/git
rofrol
2

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.

Phile binário
fonte
1
Desativar o UAC parece resolver a parte "grande" do problema para nós (atraso de vários segundos). O hack ps1 fez o resto.
precisa saber é o seguinte
Mesmo que eu estou no SSD, 32GB de RAM e i7 quad core e nenhuma das outras respostas ajudou, o UAC desativado, reinicie e comandos do git são instantâneas
phil_lgr
2

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

Mastergalen
fonte
Quero confirmar essas dicas. Excluir o git do Avast realmente torna as coisas mais rápidas. Eu vejo o status git sem esperar mais. Win 7 x64
fajarhac
Os antivírus apenas interferem.
Alex78191
1
Obrigado, foi definitivamente uma vitória rápida! Desabilitado o avast por 10 minutos, notou uma alteração instantânea no desempenho do git (ou seja, retorne aos tempos de execução normais).
Marcello Romani
Esta solução funcionou para mim. McAfee + Windows 10 Ent.
FractalSpace
1

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

George
fonte
llsendo um apelido para log? Parece estranho que haja solicitações de DNS para isso.
Michael - Onde está Clay Shirky,
1
llé um alias para ls -l. E ainda é estranho disparar uma solicitação de DNS de qualquer maneira ... Enquanto isso, ainda estou esperando o problema aparecer novamente para adicionar mais detalhes à resposta.
George
1

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.

mahacoder
fonte
Eu acho que essa resposta deveria ter mais votos. Eu vim aqui para postar essa mesma recomendação, mas vi que você já me venceu lol.
Jon
0

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.

Koshmaar
fonte
Seu problema foi causado por um script que você escreveu? Talvez esse script não é tão provável que seja a causa, para outros usuários que procurar o mesmo problema ...
Jolta
Dê uma olhada na pergunta do OP - ele mencionou muitas coisas que havia verificado, e mesmo assim não foi. O mesmo estava comigo. Então, aqui eu adicionei outra coisa a ser verificada quando nada ajuda. E não é este script específico que escrevi que é importante, mas um conceito - veja o seu PS1.
Koshmaar #
0

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.

mrcl
fonte
0

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 .

Bergmeister
fonte
Isso ajuda stash, mas o seu é o primeiro post mencionando stashespecificamente. Isso afeta outras operações do Git?
Michael - Onde está Clay Shirky
Tanto quanto eu entendo, não. Existem dois recursos experimentais na visualização que permitem ter stashe / ou rebaseusar um executável nativo para obter melhor desempenho, mas com qualquer coisa na visualização, sempre há uma pequena chance de que possa haver um pequeno efeito colateral.
precisa
1
PS Este recurso saiu de pré-visualização no v 2.19.1, portanto, você não terá a opção para mais nada
Bergmeister