Com que frequência você deve usar o git-gc?


233

Com que frequência você deve usar o git-gc?

A página do manual simplesmente diz:

Os usuários são incentivados a executar esta tarefa regularmente em cada repositório para manter uma boa utilização do espaço em disco e um bom desempenho operacional.

Existem alguns comandos para obter algumas contagens de objetos para descobrir se é hora de fazer o gc?


Tarefas como essas são as principais candidatas ao cron (se você estiver usando o linux) minhajuddin.com/2011/12/09/…
Khaja Minhajuddin

1
Nota: a configuração gc.autodetach(Git 2.0 Q2 2014) pode ajudar na execução git gc --autosem bloquear o usuário. veja minha resposta abaixo .
VonC

Respostas:


204

Depende principalmente de quanto o repositório é usado. Com um usuário fazendo check-in uma vez por dia e uma operação de ramificação / mesclagem / etc uma vez por semana, você provavelmente não precisará executá-lo mais de uma vez por ano.

Com várias dezenas de desenvolvedores trabalhando em várias dezenas de projetos, cada uma fazendo o check-in 2-3 vezes ao dia, você pode executá-lo todas as noites.

Não vai doer executá-lo com mais frequência do que o necessário, no entanto.

O que eu faria é executá-lo agora, e daqui a uma semana faça uma medição da utilização do disco, execute-o novamente e meça a utilização do disco novamente. Se cair 5%, execute-o uma vez por semana. Se cair mais, execute-o com mais frequência. Se cair menos, execute-o com menos frequência.


17
O manual diz "Alguns comandos git executam git gc --auto após executar operações que podem criar muitos objetos soltos." Alguém sabe quais comandos realmente executam?
Joshua Dance

2
Uma grande recuperação do git é um exemplo óbvio, já que muitos commits são reescritos em uma nova história - deixando muitos commit antigos no seu repo, que fazem parte do ramo atual mais
mafrosis

20
"Não vai doer executá-lo com mais frequência do que o necessário" ... não concordo inteiramente. Como Aristóteles aponta, as confirmações pendentes podem ser um bom mecanismo de backup.
Jason Baker

105

Observe que a desvantagem de coletar lixo em seu repositório é que, bem, o lixo é coletado. Como todos sabemos como usuários de computador, os arquivos que consideramos lixo agora podem se tornar muito valiosos em três dias no futuro. O fato de o git manter a maior parte de seus detritos salvou meu bacon várias vezes - ao navegar por todos os compromissos pendentes, recuperei muito trabalho que eu havia enlatado acidentalmente.

Portanto, não seja muito louco em seus clones particulares. Há pouca necessidade disso.

OTOH, o valor da recuperação de dados é questionável para repositórios usados ​​principalmente como controles remotos, por exemplo. o local em que todos os desenvolvedores pressionam e / ou puxam. Lá, pode ser sensato iniciar uma corrida de GC e reembalar frequentemente.


38
FWIW nem todos os objetos soltos são coletados como lixo, apenas aqueles com mais de duas semanas por padrão (cf. git gc --help, especificamente a --pruneopção). Também há menção de gc.reflogExpire, o que me leva a acreditar que qualquer confirmação que você visitou nos últimos 90 dias não será coletada. (Minha versão git: v1.7.6)
RobM

30

Versões recentes do git executam o gc automaticamente quando necessário, portanto você não precisa fazer nada. Veja a seção Opções do man git-gc (1) : "Alguns comandos git executam git gc --auto após executar operações que podem criar muitos objetos soltos."


13
Eu o executei pela primeira vez em um repositório de vários anos e meu .git passou de 16M para 2,9M, uma redução de 82% no tamanho. Portanto, ainda parece útil executar manualmente o comando.
Darshan Rivka Whittle

@DarshanRivkaWhittle você atualizou o git nesses vários anos?
precisa saber é o seguinte

1
@ std''OrgnlDave Sim, eu estava sempre executando a versão atual do Arch. Acabei de executá-lo novamente, talvez pela primeira vez desde o meu último comentário (graças ao seu comentário que me lembra), e meu .git passou de 81M para 13M. Eu não devo executar nenhum dos comandos que são executados gc --auto, eu acho.
Darshan Rivka Whittle

18

Se você estiver usando o Git-Gui , ele informa quando você deve se preocupar:

This repository currently has approximately 1500 loose objects.

O comando a seguir trará um número semelhante:

$ git count-objects

Exceto que, a partir de sua fonte , o git-gui fará as contas sozinho, contando algo na .git/objectspasta e provavelmente traz uma aproximação (não sei tcller direito!).

De qualquer forma, parece dar o aviso com base em um número arbitrário em torno de 300 objetos soltos.


Na verdade, ele avisa, mas, ao deixá-lo rodar gc, na maioria das vezes ele não faz nada. Portanto, contar com o git gui para fazer isso é esperar mais de 6000 objetos soltos, sempre tendo que clicar em executar gc e aguardar um minuto ou cancelar: / Provavelmente alguém deve consertar o git gui de uma forma que verifique o máximo de folga contagem de objetos e não se preocupe em mostrar a caixa de diálogo até que a contagem atinja o limite.
mlatu

Sim, eu concordo. Quando escrevi isso, eu só queria chamar a atenção. Ambos Git-Guie count-objectsnão são exatamente boas respostas para a pergunta aqui ... Mas deveriam ser!
Cregox

eu não quis dizer que esta é uma resposta ruim, só queria salientar que na maioria das vezes o git gui não faz nada. embora eu suponha que o git gc também não faça muito, exceto quando há o suficiente para fazer ou você usou o switch agressivo.
mlatu

7

Coloque-o em um trabalho cron que é executado todas as noites (tarde?) Quando você está dormindo.


7

Uso o git gc depois de fazer um checkout grande e ter muitos objetos novos. Isso pode economizar espaço. Por exemplo, se você faz o checkout de um grande projeto SVN usando git-svn e faz um git gc, normalmente economiza muito espaço


Isso ainda é verdade? Mesmo em '08 espaço HDD foi barato, usando isso como uma justificativa para executá-lo parece inútil
Timina

7

Você pode fazer isso sem nenhuma interrupção, com a nova configuração (Git 2.0 Q2 2014) gc.autodetach.

Veja commit 4c4ac4d e commit 9f673f9 ( Nguyễn Thái Ngọc Duy, também conhecido como pclouds ):

gc --autoleva tempo e pode bloquear o usuário temporariamente (mas não menos irritante).
Faça com que seja executado em segundo plano nos sistemas que o suportam.
A única coisa que se perde com a execução em segundo plano são as impressões. Mas gc outputnão é realmente interessante.
Você pode mantê-lo em primeiro plano alterando gc.autodetach.


Desde a versão 2.0, ocorreu um erro: o git 2.7 (quarto trimestre de 2015) garantirá que não perca a mensagem de erro .
Ver commit 329e6e8 (19 de setembro de 2015) por Nguyễn Thái Ngọc Duy ( pclouds) .
(Mesclado por Junio ​​C Hamano - gitster- na confirmação 076c827 , 15 de outubro de 2015)

gc: salve o log daemonizado gc --autoe imprima-o na próxima vez

Enquanto o commit 9f673f9 ( gc: opção de configuração para execução --autoem segundo plano - 2014-02-08) ajuda a reduzir algumas reclamações sobre ' gc --auto' monopolizar o terminal, ele cria outro conjunto de problemas.

O mais recente deste conjunto é, como resultado da daemonização, stderrfechado e todos os avisos são perdidos. Este aviso no final de cmd_gc()é particularmente importante porque indica ao usuário como evitar " gc --auto" executar repetidamente.
Como o stderr está fechado, o usuário não sabe, naturalmente reclamam ' gc --auto' de desperdiçar CPU.

Daemonized gcagora salva stderrem $GIT_DIR/gc.log.
O seguinte gc --autonão será executado e gc.logimpresso até o usuário removergc.log
.


6

Esta citação é retirada de; Controle de versão com Git

O Git executa a coleta de lixo automaticamente :

• Se houver muitos objetos soltos no repositório

• Quando ocorre um envio para um repositório remoto

• Após alguns comandos que podem introduzir muitos objetos soltos

• Quando alguns comandos como o git reflog expiram solicitam explicitamente

E, finalmente, a coleta de lixo ocorre quando você solicita explicitamente usando o comando git gc. Mas quando deveria ser isso? Não há uma resposta sólida para essa pergunta, mas existem alguns bons conselhos e melhores práticas.

Você deve considerar executar o git gc manualmente em algumas situações:

• Se você acabou de concluir uma ramificação do filtro git. Lembre-se de que a ramificação de filtro reescreve muitas confirmações, introduz novas e deixa as antigas em uma referência que deve ser removida quando você estiver satisfeito com os resultados. Todos os objetos mortos (que não são mais referenciados desde que você acabou de remover a referência apontada para eles) devem ser removidos por meio da coleta de lixo.

• Após alguns comandos que podem introduzir muitos objetos soltos. Isso pode ser um grande esforço de rebase, por exemplo.

Por outro lado, quando você deve tomar cuidado com a coleta de lixo?

• Se houver referências órfãs que você queira recuperar

• No contexto do git rerere e você não precisa salvar as resoluções para sempre

• No contexto de apenas tags e ramificações serem suficientes para fazer com que o Git retenha um commit permanentemente

• No contexto de recuperações FETCH_HEAD (recuperações diretas por URL via git fetch) porque elas estão imediatamente sujeitas à coleta de lixo


2
Tenho confirmações inacessíveis na minha árvore (como resultado de git commit --amend). Isso pode ser verificado com git log --reflog. Empurrei um ramo para o repositório remoto e verifiquei minha árvore novamente; os commits inacessíveis ainda estavam lá. Aparentemente, git gcnão foi executado quando esse impulso aconteceu. ...?
chharvey

4

Eu uso quando faço um grande commit, sobretudo quando removo mais arquivos do repositório .. depois, os commit são mais rápidos


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.