O que significa “Empacotando automaticamente o repositório para obter o melhor desempenho”?

Estou tendo um problema com meu repositório Git. Nos últimos dias, sempre que envio um push para o servidor, recebo a seguinte mensagem: "Empacotando automaticamente o repositório para obter o desempenho ideal", e ele parece não desaparecer e retornar o shell.

Também tentei fazer check-out para uma nova ramificação e, em seguida, refazer a minha ramificação anterior e, em seguida, git gcremover os objetos de histórico não utilizados e, em seguida, fazer um push, mas ainda assim essa mensagem aparece. Informe-me o que está acontecendo com meu repo.

Versão curta: significa o que diz e, se você deixar terminar, tudo ficará bem.

Durante a maioria das operações que podem aumentar potencialmente o número de objetos soltos (descompactados) no repositório (incluindo pushes), o Git chama git gc --auto. Se houver objetos soltos suficientes (por padrão, pelo menos 6700), ele será chamado git repack -d -lpara compactá-los. Se houver muitos pacotes separados, ele também será reembalado em um.

Um pacote é um arquivo único compactado em delta, contendo um grande número de objetos. É mais eficiente armazenar objetos em pacotes, mas leva tempo para compactar (compactar) objetos, para que o Git crie objetos soltos inicialmente e os empacote em lotes de vez em quando, por meio da invocação automática de git gc --auto.

Se você deixar o Git terminar de reembalar, isso não acontecerá novamente por um tempo. De fato, pode demorar um pouco, especialmente se você tiver muitos objetos binários grandes, mas se estiver sendo acionado, é um sinal de que provavelmente reduzirá drasticamente a quantidade de espaço em disco ocupado pelo repositório. Se você realmente não quer que isso aconteça, você pode alterar o parâmetro de configuração gc.auto. Se você aumentar para algo muito maior que 6700, isso acontecerá com menos frequência, mas levará mais tempo. Se você diminuí-lo, ainda terá que fazer sua reembalagem atual, mas subsequentemente isso acontecerá com mais frequência e terminará mais rapidamente. Se você defini-lo como 0, desabilitará a reembalagem automática.

Consulte man git-gc(abaixo --auto) e man git-config(abaixo gc.auto) para obter mais informações.

Embora o Jefroni esteja certo de que às vezes o empacotamento automático precisa de tempo para ser concluído, se a mensagem do empacotamento automático persistir por vários dias, conforme a descrição do OP, há uma boa chance de que a limpeza do git esteja perdendo objetos pendentes, conforme descrito nesta pergunta .

Para ver se os objetos pendentes estão acionando mensagens em andamento sobre empacotamento automático, tente executar git fsck. Se você receber uma longa lista de confirmações pendentes, poderá limpá-las com

git gc --prune=now

Normalmente, eu tenho que executar isso no meu repositório a cada 2-3 meses, quando a mensagem de empacotamento automático não desaparece após um único puxão.

Para desativar para um projeto:

cd your_project_dir
git config gc.auto 0

Para desativar globalmente:

git config --global gc.auto 0

O Git está executando o git-repack, que empacota muitos objetos (= arquivos, confirmações e árvores) em um arquivo de pacote. O Git faz isso algumas vezes, quando uma heurística diz que pode haver espaço economizado (um arquivo de pacote contém deltas de objetos compactados, enquanto cada arquivo no diretório de objetos / contém o conteúdo completo do arquivo)

Felizmente, essa git gc --autoetapa é agora (git 2.0.1, 25 de junho de 2014) mais eficiente.
Veja commit 62aad18 de Nguyễn Thái Ngọc Duy ( pclouds)

gc --auto: não bloqueie refs em segundo plano

9f673f9 ( gc: opção de configuração para executar --auto em segundo plano - 08-02-2014, Git 2.0.0) coloca " gc --auto" em segundo plano para reduzir o tempo de espera do usuário.
Parte da coleta de lixo são refs de embalagens e reflogs de poda. Isso requer o bloqueio de algumas referências e pode abortar outros processos que tentam bloquear a mesma referência.

Se gc --autofor disparado no meio de um script, os bloqueios de retenção do gc em segundo plano poderão falhar no script, o que nunca poderia acontecer antes do 9f673f9 .

Continue executando pack-refse " reflog --prune" em primeiro plano para interromper atualizações de ref paralelas. As demais operações em segundo plano (reembalar, remover e rerere) não devem afetar os processos git em execução.

E o Git 2.22 (Q2 2019) otimiza ainda maisgit gc .