Git
Português (Brasil) ▾ Topics ▾ Latest version ▾ git-pack-objects last updated in 2.43.0

NOME

git-pack-objects - Crie um arquivo compactado dos objetos

RESUMO

git pack-objects [-q | --progress | --all-progress] [--all-progress-implied]
	[--no-reuse-delta] [--delta-base-offset] [--non-empty]
	[--local] [--incremental] [--window=<n>] [--depth=<n>]
	[--revs [--unpacked | --all]] [--keep-pack=<nome-do-pacote>]
	[--cruft] [--cruft-expiration=<tempo>]
	[--stdout [--filter=<filter-spec>] | <nome-base>]
	[--shallow] [--keep-true-parents] [--[no-]sparse] < <lista-do-objeto>

DESCRIÇÃO

Lê a lista dos objetos da entrada padrão e grava um ou mais arquivos compactados com o nome da base informada no disco ou num arquivo compactado na saída padrão.

Um arquivo compactado é uma maneira eficiente de transferir um conjunto de objetos entre dois repositórios, além de ser um formato de arquivamento com acesso eficiente. Num arquivo compactado, um objeto é armazenado como um todo compactado ou como uma diferença de algum outro objeto. Este último é geralmente chamado de delta.

O formato do arquivo compactado (.pack) foi projetado para ser independente, para que possa ser descompactado sem nenhuma informação adicional. Portanto, cada objeto onde um delta seja dependente, deve estar presente no pacote.

Um arquivo do índice do pacote (.idx) é gerado para acesso rápido e aleatório aos objetos do pacote. Colocar tanto o arquivo de índice (.idx) quanto o arquivo compactado (.pack) no subdiretório pack/ de $GIT_OBJECT_DIRECTORY (ou qualquer um dos diretórios em $GIT_ALTERNATE_OBJECT_DIRECTORIES) permite que o Git leia o arquivo compactado.

O comando git unpack-objects pode ler o arquivo compactado e expandir os objetos existentes no pacote no formato "um-arquivo, um-objeto"; isso geralmente é feito pelos comandos smart-pull quando um pacote é criado em tempo real por um transporte de rede eficiente pelos seus pares.

OPÇÕES

base-name

Escreva em pares de arquivos (.pack e .idx), usando <nome-base> para determinar o nome do arquivo criado. Quando essa opção é usada, os dois arquivos num par são gravados em arquivos <nome-base>-<SHA-1>.{pack,idx}. <SHA-1> é um hash baseado no conteúdo do pacote sendo gravado na saída predefinida do comando.

--stdout

Escreva o conteúdo do pacote (o que teria sido gravado no arquivo .pack) na saída padrão.

--revs

Ler os argumentos de revisão da entrada predefinida, em vez dos nomes dos objetos individuais. Os argumentos de revisão são processados da mesma forma que o comando git rev-list com a opção --objects usa seus argumentos commit para criar a lista de objetos que produz. Os objetos da lista resultante são empacotados. Além das revisões, as opções --not ou --shallow <SHA-1> também são aceitas.

--unpacked

Implica no uso da opção --revs. Ao processar a lista com argumentos de revisão lidos na entrada predefinida, limite os objetos empacotados àqueles que ainda não foram empacotados.

--all

Implica no uso da opção --revs. Além da lista de argumentos da revisão lidos na entrada predefinida, finja que todas as referências em refs/ estejam definidas para serem incluídas.

--include-tag

Inclua as etiquetas anotadas não solicitadas se o objeto de onde elas fazem referência foi incluído no arquivo resultante do pacote. Isso pode ser útil para enviar novas etiquetas para clientes nativos do Git.

--stdin-packs

Lê os nomes base dos arquivos de pacote (pack-1234abcd.pack por exemplo) da entrada predefinida, em vez dos nomes dos objetos ou das opções de revisão. O pacote resultante contém todos os objetos listados nos pacotes incluídos (aqueles que não começam com ^), excluindo todos os objetos listados nos pacotes excluídos (que começam com ^).

É incompatível com a opção --revs, ou opções que impliquem no uso de --revs (como --all), menos com a opção --unpacked, que é compatível.

--cruft

Empacota objetos inacessíveis num pacote "cruft" (simples) separado, denotado pela existência de um arquivo .mtimes. É normalmente é utilizado por git repack --cruft. Aqueles que os invocam fornecem uma lista dos nomes dos pacotes e indicam quais os pacotes permanecerão no repositório, juntamente com quais pacotes serão excluídos (indicado pelo prefixo -). O conteúdo do pacote "cruft" são todos os objetos não contidos nos pacotes sobreviventes que não excederam o período de carência (consulte --cruft-expiration abaixo), ou que excederam o período de carência, mas são acessíveis a partir de um outro objeto que não o tem.

Quando a entrada listar um pacote contendo todos os objetos alcançáveis (e listar todos os outros pacotes como exclusão pendente), o pacote "cruft" correspondente conterá todos os objetos inalcançáveis (com mtime mais recente que --cruft-expiration) junto com quaisquer objetos inalcançáveis cujos mtime seja mais antigo que o --cruft-expiration, e seja acessível a partir de um objeto inacessível cujo mtime seja mais recente que --cruft-expiration).

É incompatível com as opções --unpack-unreachable, --keep-unreachable, --pack-loose-unreachable, --stdin-packs, bem como quaisquer outras opções que impliquem --revs.

--cruft-expiration=<aproximado>

Se definido, os objetos são eliminados do pacote "cruft" caso tenham um mtime mais antigo que <aproximado>. Se não for definido (e for usado --cruft), nenhum objeto será eliminado.

--window=<n>
--depth=<n>

Estas duas opções afetam a maneira como os objetos contidos no pacote são armazenados usando a compactação delta. Os objetos são primeiro classificados internamente por tipo, tamanho e, opcionalmente, por nomes, e também comparados com os outros objetos dentro em conjunto com a opção --window para verificar se o uso da compactação delta economiza espaço. A opção --depth limita a profundidade delta máxima; torná-la muito profunda afeta o desempenho para quem for descompactar, pois os dados delta precisam ser aplicados muitas vezes para chegar ao objeto necessário.

O valor predefinido para a opção --window é 10 e o --depth é 50. O valor da profundidade máxima é 4095.

--window-memory=<n>

Esta opção fornece um limite adicional além da opção --window; o tamanho da janela será reduzido dinamicamente para não ocupar mais do que <n> bytes na memória. Isso é útil em repositórios com uma mistura de objetos grandes e pequenos evitando a falta de memória com uma janela grande, mas ainda assim ser possível aproveitar a grande janela para os objetos menores. O tamanho pode ser sufixado com "k", "m" ou "g". A opção --window-memory=0 torna ilimitado o uso da memória. A predefinição é obtida a partir na variável de configuração pack.windowMemory.

--max-pack-size=<n>

Em cenários incomuns, talvez não seja possível criar arquivos maiores do que um determinado tamanho no sistema de arquivos, e essa opção pode ser usada para informar ao comando para dividir o pacote do arquivo gerado em vários arquivos independentes, cada um não maior do que o tamanho informado. O tamanho pode ser sufixado com "k", "m" ou "g". O tamanho mínimo permitido é limitado a 1 MiB. A predefinição é ilimitado, a menos que outro valor seja definido na variável de configuração pack.packSizeLimit. Observe que esta opção pode resultar num repositório maior e mais lento; consulte a discussão em pack.packSizeLimit.

--honor-pack-keep

Esta opção faz com que um objeto que já esteja num pacote local que possua um arquivo .keep seja ignorado, mesmo que já tivesse sido compactado.

--keep-pack=<nome-do-pacote>

Esta opção faz com que um objeto que já esteja no pacote informado seja ignorado, mesmo que ele tivesse sido compactado. O <nome-do-pacote> é o nome do arquivo do pacote sem o diretório principal (por exemplo, pack-123.pack). A opção pode ser utilizada várias vezes para manter os vários pacotes.

--incremental

Esta opção faz com que um objeto que já esteja num pacote seja ignorado, mesmo que ele tenha sido compactado.

--local

Esta opção faz com que um objeto emprestado de um armazenamento de objetos alternativo seja ignorado, mesmo que já tivesse sido compactado.

--non-empty

Crie apenas um arquivo compactado caso ele contenha pelo menos um objeto.

--progress

É predefinido que a condição geral do progresso seja relatada no fluxo de erros quando estiver conectado num terminal, a menos que -q seja utilizado. Esta opção impõem a condição geral do progresso, mesmo que o fluxo de erro predefinido não seja direcionado para um terminal.

--all-progress

Quando a opção --stdout é usada, o relatório de progresso é exibido durante a contagem dos objetos e das fases de compactação, mas é inibido durante a fase de gravação. O motivo disso, em alguns casos, é por causa do fluxo de saída que está diretamente vinculado a outro comando que pode querer exibir a condição do progresso enquanto processa os dados do pacote na entrada. Esta opção funciona como --progress, exceto pelo fato dele impor o relatório de progresso também para a fase de gravação, ainda que a opção --stdout seja usada.

--all-progress-implied

Isto é usado para indicar sempre que a exibição de progresso --all-progress estiver ativada. Ao contrário de --all-progress, esta opção não impõem nenhuma exibição de progresso por si só.

-q

Esta opção faz com que o comando não relate o seu progresso em meio ao fluxo de erros já predefinido.

--no-reuse-delta

Ao criar um arquivo compactado num repositório que tenha pacotes já existentes, o comando reutilizará tais deltas. Isso às vezes resulta num pacote ligeiramente abaixo do ideal. Esta opção informa ao comando para não reutilizar os deltas já existentes, e sim para calculá-los do zero.

--no-reuse-object

Esta opção informa ao comando para não reutilizar os dados do objeto já existente, inclusive o objeto não deltificado, impondo a recompressão de tudo. Implica no uso da opção --no-reuse-delta. Útil apenas em casos obscuros onde se deseja a aplicação total de um nível de compactação diferente nos dados compactados.

--compression=<n>

Especifica o nível de compactação dos dados recém-compactados no pacote que foi gerado. Se não for especificado, o nível de compactação do pacote será determinado primeiro por pack.compression e, em seguida, por core.compression, e a predefinição será -1, a predefinição zlib, caso nenhum dos dois tenha sido definido. Adicione a opção --no-reuse-object se quiser impor um nível de compactação uniforme em todos os dados, independentemente da origem.

--[no-]sparse

Alterna o algoritmo "sparse" para determinar quais os objetos devem ser incluídos no pacote, quando combinado com a opção --revs. Este algoritmo percorre apenas as árvores que aparecem em caminhos que introduzem novos objetos. Isso pode trazer significativos benefícios de desempenho ao computar um pacote e enviar uma pequena alteração. No entanto, é possível que os objetos extras sejam adicionados ao arquivo do pacote se os commits incluídos tiverem determinados tipos diretos de renomeações. Caso esta opção não seja incluída, a predefinição será o valor em pack.useSparse, que é verdadeiro, a menos que outra opção seja especificada.

--thin

Crie um pacote "magro" ao omitir objetos comuns entre o remetente e o destinatário visando a redução do tráfego de rede. Esta opção só faz sentido se utilizado em conjunto com --stdout.

Observação: Um pacote leve viola o formato do arquivo compactado por omitir os objetos necessários e portanto, não pode ser utilizado pelo Git sem torná-lo independente. Para restaurar as propriedades deste pacote utilize o comando git index-pack --fix-thin (consulte git-index-pack[1]).

--shallow

Otimize um pacote que será fornecido a um cliente com um repositório superficial. Essa opção, combinada com --thin, pode resultar num pacote menor à custa da velocidade.

--delta-base-offset

Um arquivo compactado pode expressar o objeto base de um delta como um nome de objeto com 20 bytes ou como um offset no fluxo, porém, versões antigas do Git não compreendem este último. Para maior compatibilidade, é predefinido que o comando git pack-objects use apenas o formato anterior. Esta opção permite que o comando use o último formato para fins de compactação. Dependendo do comprimento médio da cadeia delta, esta opção normalmente reduz o tamanho do arquivo resultante de 3 a 5%.

Observação: Comandos porcelana como git gc (consulte git-gc[1]), git repack (consulte git-repack[1]) repassam esta opção ao Git atual quando colocam objetos em seu repositório ou em pacotes de arquivos. O mesmo acontece com o comando git bundle (consulte git-bundle[1]) quando ele cria um pacote.

--threads=<n>

Especifica a quantidade de threads que serão gerados durante a pesquisa das melhores correspondências delta. Isso requer que o pack-objects seja compilado com pthreads; caso contrário, esta opção será ignorada e exibirá um aviso. O objetivo é reduzir o tempo de empacotamento em máquinas com vários processadores. No entanto, a quantidade de memória necessária para a janela de pesquisa delta é multiplicada pelo número de threads. Ao definir como 0, fará com que o Git detecte automaticamente a quantidade de CPUs e defina a quantidade de threads automaticamente.

--index-version=<version>[,<offset>]

Isso foi pensado para ser utilizado apenas pelo conjunto de testes. Ele permite impor a versão do índice do pacote gerado e impor as entradas no índice com 64 bits nos objetos localizados acima da compensação informada.

--keep-true-parents

Com esta opção, as origens são ocultas pelos enxertos são embalados mesmo assim.

--filter=<filter-spec>

Omite determinados objetos (geralmente bolhas) do pacote resultante de arquivos. Consulte git-rev-list[1] para formas de <spec-do-filtro> válidos.

--no-filter

Desliga qualquer argumento --filter= anterior.

--missing=<missing-action>

Uma opção de depuração para ajudar no desenvolvimento futuro de "clones parciais". Esta opção determina como lidar com os objetos ausentes.

A opção --missing=error solicita que o pack-objects interrompa o processo com um erro caso encontre um objeto ausente. Caso o repositório seja um clone parcial, será feita uma tentativa de obter os objetos ausentes antes de declará-los ausentes. Esta é a ação predefinida.

A opção --missing=allow-any permitirá que o encaminhamento do objeto continue no caso de um objeto ausente ter sido encontrado. Não ocorrerá a obtenção de um objeto caso esteja ausente. Os objetos ausentes serão silenciosamente omitidos dos resultados.

A opção --missing=allow-promisor é como allow-any, mas só permitirá que o encaminhamento do objeto continue para os objetos ausentes e ESPERADOS do promissor. Não ocorrerá a obtenção de um objeto caso esteja ausente. Será gerado um erro caso um objeto inesperado esteja ausente.

--exclude-promisor-objects

Omite objetos que conhecidamente estejam num ramo promisor remoto. (Esta opção tem a finalidade de operar somente em objetos criados localmente, para que, quando forem reempacotamos, ainda manteremos uma distinção entre os objetos criados localmente [sem .promisor] e os objetos do "promisor" remoto [com .promisor]). Isso é usado com o clone parcial.

--keep-unreachable

Os objetos inacessíveis das refs nos pacotes informado com a opção --unpacked= são adicionados ao pacote gerado, além dos objetos acessíveis que não estão nos pacotes marcados com arquivos *.keep. Implica no uso da opção --revs.

--pack-loose-unreachable

Embale os objetos soltos que estejam inacessíveis (e as suas contrapartes soltas que foram removidas). Implica no uso da opção --revs.

--unpack-unreachable

Mantenha os objetos inacessíveis de forma solta. Implica no uso da opção --revs.

--delta-islands

Restrinja a coincidência delta com base nas "ilhas". Consulte ILHAS DELTA abaixo.

ILHAS DELTA

Quando possível, o pack-objects tenta reutilizar os deltas existentes no disco para evitar ter que procurar por novos em tempo real. Esta é uma otimização importante a serviço das buscas (fetch), significa que o servidor pode evitar inflar a maioria dos objetos e enviar os bytes diretamente do disco. Esta otimização pode não funcionar quando um objeto é armazenado como um delta numa base onde o destinatário não o possua (e que não estamos enviando ainda). Nesse caso, o servidor "quebra" o delta e precisa encontrar um novo, ao custo de um alto processamento. Portanto, é importante para o desempenho que o conjunto dos objetos delta nos relacionamentos com o disco corresponda ao que um cliente buscaria.

Em um repositório normal, isso tende a funcionar de forma automática. Os objetos são acessíveis principalmente a partir dos ramos e tags e é isso que os clientes buscam. Qualquer delta que encontrarmos no servidor, provavelmente estará entre os objetos que o cliente possui ou terá.

Porém em algumas configurações do repositório, é possível ter vários grupos relacionados, mas separados, das dicas de referência, com os clientes tendendo a buscar estes grupos de forma independente. Por exemplo, imagine que você esteja hospedando várias "bifurcações" de um repositório num único armazenamento dos objetos compartilhados e permitindo que os clientes os visualizem como repositórios separados por meio de GIT_NAMESPACE ou repositórios separados, utilizando o mecanismo alternativo. Um um simples reempacotamento pode achar que o delta ideal para um objeto está contra uma base que é encontrada apenas em outra bifurcação. Porém quando um cliente realiza uma busca, ele não terá o objeto base e teremos que encontrar um novo delta em tempo real.

Uma situação semelhante pode existir caso você tenha muitos refs fora de refs/heads/ e refs/tags/ que apontam para os objetos relacionados (por exemplo, refs/pull ou refs/changes utilizados por alguns provedores de hospedagem). É predefinido que os clientes busquem apenas os cabeçalhos e tags, os deltas nos objetos encontrados apenas nesses outros grupos não podem ser enviados como estão.

As ilhas Delta resolvem este problema, permitindo que você agrupe as suas refs em "ilhas" distintas. Os pacotes de objetos calcula quais os objetos estão acessíveis a partir das ilhas e recusando-se a fazer um delta de um objeto A contra uma base que não está presente em todas as ilhas A. Isso resulta em pacotes um pouco maiores (porque perdemos algumas oportunidades delta), mas garante que uma busca por uma ilha não tenha que recalcular os deltas em tempo real, devido ao cruzamento dos limites da ilha.

Ao realizar um reempacotamento com ilhas delta, a janela delta tende a ficar entupida com os candidatos barrados pela configuração. O reempacotamento com uma grande --window ajuda (e não leva tanto tempo quanto poderia, porque podemos rejeitar alguns pares de objetos com base nas ilhas antes de realizar qualquer cálculo no conteúdo).

As ilhas são configuradas através da opção pack.island, que pode ser utilizada várias vezes. Cada valor é uma expressão regular ancorada à esquerda que coincidam com "refnames". Por exemplo:

[pack]
island = refs/heads/
island = refs/tags/

coloca os cabeçalhos e as tags numa ilha (cujo nome é um texto vazio; veja abaixo para conhecer mais nomenclaturas). Qualquer refs que não coincida com estas expressões regulares (refs/pull/123 por exemplo) não está em nenhuma ilha. Qualquer objeto acessível apenas a partir do refs/pull/ (mas não nos cabeçalhos ou nas tags) não é portanto, um candidato a ser utilizado como base para refs/heads/.

Os árbitros são agrupados em ilhas com base nos seus "nomes" e duas expressões regulares que produzam o mesmo nome, são consideradas para estarem na mesma ilha. Os nomes são calculados a partir das expressões regulares concatenando quaisquer grupos de captura da expressão regular, com um traço - no meio. (E caso não haja grupos de captura, o nome será uma sequência de texto vazia, como no exemplo acima.) Isso permite criar números arbitrários das ilhas. Apenas até 14 desses grupos de captura são compatíveis.

Por exemplo, imagine que você armazene as refs para cada bifurcação em refs/virtual/ID, onde o ID é um identificador numérico. Você pode então configurar:

[pack]
island = refs/virtual/([0-9]+)/heads/
island = refs/virtual/([0-9]+)/tags/
island = refs/virtual/([0-9]+)/(pull)/

Coloca os cabeçalhos e as tags de cada bifurcação na sua própria ilha (chamada "1234" ou similar), e as refs do "pull" de cada um entram no seu próprio "1234-pull".

Observe que escolhemos uma única ilha para cada regex, utilizando a ordem "last one wins" ou "o último vence" (que permite que determinada configuração do repo tenha precedência sobre a configuração do usuário e assim por diante).

CONFIGURAÇÃO

As várias variáveis de configuração afetam o empacotamento, consulte git-config[1] (pesquise por "pack" e "delta").

Notavelmente, a compressão delta não é usada nos objetos maiores que a variável de configuração core.bigFileThreshold e nos arquivos com o atributo` delta` definido como falso.

GIT

Parte do conjunto git[1]

scroll-to-top