10.4 Git Internals (Por Dentro do Git) - Arquivos de pacote (Packfiles)

Se você seguiu todas as instruções de exemplo da seção anterior, agora você deve ter um repositório Git de teste com 11 objetos — quatro blobs, três trees (árvores), três commits e uma tag:

O Git comprime o conteúdo desses arquivos com zlib e, como você não está armazenando muita coisa, todos esses arquivos juntos ocupam apenas 925 bytes. Agora você vai adicionar mais conteúdo de tamanho razoável ao repositório para demonstrar uma funcionalidade interessante do Git. Para demonstrar, nós adicionaremos o arquivo repo.rb da biblioteca do Grit — que é um arquivo de código-fonte de aproximadamente 22K:

Se você olhar para a árvore resultante, você poderá ver o valor SHA-1 que foi calculado para o seu novo objeto blob repo.rb:

Você pode então usar o git cat-file para ver quão grande é esse objeto:

Neste momento, faça uma pequena modificação nesse arquivo e veja o que acontece:

Ao conferir a árvore criada por esse último commit, você verá algo interessante:

O blob agora é um blob diferente, o que significa que, embora você tenha adicionado apenas uma única linha ao final de um arquivo de 400 linhas, o Git armazenou esse novo conteúdo como um objeto completamente novo:

Você tem dois objetos de 22K quase idênticos em seu disco (cada um comprimido para aproximadamente 7K). Não seria legal se o Git pudesse armazenar um deles na íntegra, mas então para o segundo objeto o Git armazenasse apenas o delta entre ele e o primeiro?

Acontece que ele pode. O formato inicial em que o Git salva objetos no disco é chamado de formato de objeto “loose” (solto). No entanto, ocasionalmente, o Git empacota (packs) vários desses objetos num único arquivo binário chamado de “packfile” (arquivo de pacote) a fim de economizar espaço e ser mais eficiente. O Git faz isso se você tiver muitos objetos loose soltos, se você rodar o comando git gc manualmente, ou se você os submeter (push) ao servidor remoto. Para ver o que acontece, você pode pedir ao Git para empacotar os objetos chamando o comando git gc:

Se você olhar em seu diretório objects, você notará que a maioria de seus objetos sumiu e um novo par de arquivos apareceu:

Os objetos que permanecem são os blobs que não são apontados por nenhum commit — neste caso, o exemplo “what is up, doc?” e os blobs de exemplo “test content” que você criou anteriormente. Como você nunca os adicionou a nenhum commit, eles são considerados dangling (soltos/perdidos) e não são empacotados no seu novo packfile.

Os outros arquivos são o seu novo arquivo packfile e um índice. O packfile é um único arquivo que abrange o conteúdo de todos os objetos que foram removidos do seu sistema de arquivos. O índice é um arquivo que contém os offsets (deslocamentos) para que você possa buscar e encontrar de forma veloz para algum objeto mais específico. O que é legal é que, embora os objetos no disco antes de você executar o comando gc tivessem juntos em média 15K de tamanho, o novo arquivo de pacote (packfile) tem apenas 7K. Você cortou pela metade a utilização do seu disco em virtude pelo empacotamento de seus objetos.

Como o Git faz isso? Quando o Git empacota objetos, ele procura por arquivos que tenham nomes e tamanhos semelhantes e armazena apenas os deltas (as diferenças) de uma versão do arquivo para a próxima. Você pode olhar no arquivo packfile e ver o que o Git fez para poupar mais espaço. O comando plumbing git verify-pack permite que você veja tudo o que foi empacotado:

Aqui, o blob 033b4, que se você bem se lembrar era a primeira versão do seu arquivo repo.rb, está fazendo a referência ao blob b042a, que se tratava da segunda versão do arquivo. A terceira coluna na saída é o tamanho do objeto no pack (pacote), de modo que você possa ver que b042a consome 22K do arquivo, mas que 033b4 leva apenas 9 bytes. O que também é interessante é que a segunda versão do arquivo é a única que é armazenada de forma intacta, enquanto a versão original é armazenada como delta — isso ocorre porque é mais provável que você precise de um acesso mais rápido à versão mais recente do arquivo.

A parte muito interessante em tudo isso é que ela pode ser repacotada a qualquer momento. Ocasionalmente o Git reempacota o seu banco de dados automaticamente, sempre visando tentar economizar mais espaço, mas você pode também o reempacotar a qualquer momento que quiser ao se rodar com a manualidade através do git gc pelas suas próprias mãos.