etckeeper com git, uma maneira de lidar com repo enorme

Question

Descobri recentemente que /etc/.git/ atingiu cerca de 30G [sic!] de espaço em disco. Este repo é apenas para etckeeper . Eu tenho uma pequena experiência com o git.

Eu criei duas soluções:

1. Obviamente, exclua commits antigos (acima de um ano). Mas os bcommits podem ser dependentes de alguma forma?
2. git gc é outro. Eu nunca fiz isso antes, só li git help gc . É dito que o uso deste comando é encorajado. Então, como eu entendo, apenas a estrutura interna (e alguma coleta de lixo) é alterada e a clonagem, obtendo um commit e commit ainda é possível sem nenhuma mudança, e os dados não são afetados?

O que é uma boa prática nesse caso?

    

Answer 1

A ideia de git gc é remover objetos que não estão mais acessíveis. Como etckeeper simplesmente adiciona commits, isso provavelmente não ajudará muito. Mas não vai doer e talvez economizar um pouco de espaço através de reembalagem.

Você provavelmente conseguiu um arquivo enorme em /etc/ no passado, que agora ainda está no histórico do git. Ou jogue fora toda a história do seu git. (No caso de / etc / isso pode ser uma opção.) Ou tente remover o arquivo enorme do seu histórico. Dê uma olhada no Repo-Limpador da BFG .

    

Answer 2

Seus repositórios provavelmente contêm alguns arquivos grandes no histórico. Você pode dar a saída de du -hs , por favor? Isso esclareceria se algum desses arquivos está no diretório /etc atual e, portanto, no HEAD dos gitkeeper /etc git repos. Uma abordagem mais interativa é usar a ferramenta útil ncdu . Se houver arquivos grandes desnecessários no diretório /etc atual, você poderá excluí-los. No entanto, assumirei no restante desta resposta que eles estão principalmente no histórico e não no diretório /etc atual.

Uma opção é reescrever os repositórios git para remover esses arquivos grandes. Isso ocorreria em duas etapas.

1. Identifique os arquivos grandes.
2. Reescreva os repositórios para remover esses arquivos.

Observe que o HEAD do repositório permanecerá o mesmo, portanto, isso não afetará o diretório /etc .

Eu estava recentemente envolvido na periferia fazendo exatamente isso por um git repos (não o meu próprio). Se você quiser mais detalhes, eu poderia tentar desenterrá-los. No entanto, a abordagem utilizada foi muito manual e DIY. Das pessoas envolvidas, nenhuma delas, inclusive eu, era uma especialista em gits. Portanto, se houver ferramentas existentes para automatizar isso, isso pode ser melhor.

    

Answer 3

Espero que este seja o lugar para fechar a questão, agradeço pela ajuda e acrescente uma explicação, alguém pode achar útil.

Então, eu sei o que causou o problema. Como aconteceu, um ldb do SAMBA4 / AD estava em /etc/ ; o arquivo tem cerca de 500MB e o git estava fazendo um snapshot de todo o arquivo se algo no banco de dados foi alterado. O repo tinha cerca de um ano de idade, por isso o tamanho era apropriado;)

Dicas úteis:

• O repositório do Git é autocontido, portanto, cp -r ( scp , ...) é viável.
• Git internamente é um monte de blobs (principalmente), então a compactação não é útil.
• git gc verifica objetos indisponíveis e, às vezes, compacta itens, mas por causa do ponto anterior não é tão eficaz em termos de economia de espaço em disco.

Portanto, a solução era simplesmente fazer backup do repositório (archive ou clone para a versão mais recente), removê-lo e invocar em /etc/ :

etckeeper init e etckeeper commit "First message in new repo."

E talvez adapte .gitignore para atender às suas necessidades. Obrigado pelas respostas, ambos foram úteis e corretos.

    

Answer 4

Eu tenho pouca experiência com o git, então só posso dar algumas dicas do usuário iniciante. Quero dizer, o que eu aprendi depois de versionar /etc e outras pastas, é que a solução mais fácil é sempre a melhor. Dizendo isso, eu quero manter a regra KISS (imagine-se tendo que liberar rapidamente algum espaço em disco). Como você vai fazer isso, sabendo que não precisa manter o histórico de log /etc ? Soluções complexas estão bem, se você tiver tempo não está sob pressão para mantê-lo.

No seu caso - e na verdade também na minha - a solução ideal foi simplesmente remover a subpasta .git e inicializar novamente o repo. Eu sei que é a solução mais fácil e nem sempre aplicável, mas lembre-se - pressão, tempo, simplicidade, então procure a solução mais fácil.

    

Answer 5

O enorme repo está em /etc/.git. Se você não precisa manter esse histórico, pode simplesmente excluir esse repositório git inteiramente pelos seguintes métodos:

1) Exclua o diretório .git manualmente com 'rm -rf .git' - Eu consideraria isso uma opção de falta de espaço na emergência. Eu não sei se o freak do etckeeper ou o que, mas isso definitivamente consertará a situação. Referência do Stackoverflow: link

2) A outra opção é fazer a mesma coisa usando o próprio etckeeper . Do site do etckeeper:

"Is the history recorded in that repository something you need to preserve, or can you afford to just blow it away and check the current /etc into the new VCS?

In the latter case, you just need to follow three steps:

etckeeper uninit # deletes /etc/.git!
vim /etc/etckeeper/etckeeper.conf
etckeeper init

Referência: link

Você não precisa alterar o VCS editando o arquivo etckeeper.conf. Se você deixar o etckeeper VCS sozinho e fizer o "etckeeper init", ele apenas iniciará um novo repositório usando o git com o estado atual do diretório / etc.

Aqui está outra referência do Turnkey Linux:

etckeeper has HUGE .git repo, how to remove???

Resposta aceita pelos mantenedores: "Executar: etckeeper uninit -f; etckeeper init"

Eu estava ficando sem espaço. Acabei de fazer o passo acima e apaguei 15 GB de histórico desnecessário. Eu acho que o etckeeper é ótimo para monitorar o diretório / etc continuamente, mas eu não preciso de 2 anos de história.