O livro Git contém um artigo sobre o que um índice inclui :
O índice é um arquivo binário (geralmente mantido .git/index
) contendo uma lista classificada de nomes de caminhos, cada um com permissões e o SHA1 de um objeto de blob; git ls-files
pode mostrar o conteúdo do índice:
$ git ls-files --stage
100644 63c918c667fa005ff12ad89437f2fdc80926e21c 0 .gitignore
100644 5529b198e8d14decbe4ad99db3f7fb632de0439d 0 .mailmap
O problema do Racy git fornece mais alguns detalhes sobre essa estrutura:
O índice é uma das estruturas de dados mais importantes no git.
Ele representa um estado da árvore de trabalho virtual gravando a lista de caminhos e seus nomes de objetos e serve como uma área intermediária para gravar o próximo objeto de árvore a ser confirmado.
O estado é "virtual" no sentido de que não precisa necessariamente, e geralmente não corresponde, aos arquivos na árvore de trabalho.
Para ver mais, cf. " git / git / Documentation / technical / index-format.txt ":
O arquivo de índice Git tem o seguinte formato
Todos os números binários estão na ordem dos bytes da rede.
A versão 2 é descrita aqui, salvo indicação em contrário.
- Um cabeçalho de 12 bytes que consiste em:
- Assinatura de 4 bytes :
a assinatura é {' D
', ' I
', ' R
', ' C
'} (significa " dircache
")
- Número da versão de 4 bytes :
as versões suportadas atualmente são 2, 3 e 4.
- Número de 32 bits de entradas de índice.
- Um número de entradas de índice classificadas .
- Extensões : as
extensões são identificadas por assinatura.
Extensões opcionais podem ser ignoradas se o Git não as entender.
Atualmente, o Git suporta a árvore em cache e resolve as extensões de desfazer.
- Assinatura de extensão de 4 bytes. Se o primeiro byte for '
A
' .. ' Z
', a extensão é opcional e pode ser ignorada.
- Tamanho de 32 bits da extensão
- Dados de extensão
- SHA-1 de 160 bits sobre o conteúdo do arquivo de índice antes desta soma de verificação.
mljrg comentários :
Se o índice é o local onde a próxima consolidação é preparada, por que " git ls-files -s
" não retorna nada após a consolidação?
Como o índice representa o que está sendo rastreado e logo após um commit, o que está sendo rastreado é idêntico ao último commit ( git diff --cached
não retorna nada).
Então, git ls-files -s
lista todos os arquivos rastreados (nome do objeto, bits de modo e número do estágio na saída).
Essa lista (de elemento rastreado) é inicializada com o conteúdo de uma confirmação.
Quando você alterna a ramificação, o conteúdo do índice é redefinido para o commit referenciado pela ramificação para a qual você acabou de alternar.
O Git 2.20 (quarto trimestre de 2018) adiciona uma tabela de deslocamento de entrada de índice (IEOT) :
Consulte commit 77ff112 , commit 3255089 , commit abb4bb8 , commit c780b9c , commit 3b1d9e0 , commit 371ed0d (10 de outubro de 2018) por Ben Peart ( benpeart
) .
Veja commit 252d079 (26 de setembro de 2018) de Nguyễn Thái Ngọc Duy ( pclouds
) .
(Mesclado por Junio C Hamano - gitster
- in commit e27bfaa , 19 de outubro de 2018)
ieot: adicionar extensão da tabela de deslocamento de entrada de índice (IEOT)
Esse patch permite abordar o custo da CPU de carregar o índice adicionando dados adicionais ao índice que nos permitirá multiencadear com eficiência o carregamento e a conversão de entradas de cache.
Isso é feito adicionando uma extensão de índice (opcional) que é uma tabela de compensações a blocos de entradas de cache no arquivo de índice.
Para que isso funcione nos índices V4, ao gravar as entradas de cache, "redefine" periodicamente a compactação do prefixo, codificando a entrada atual como se o nome do caminho da entrada anterior fosse completamente diferente e salvasse o deslocamento dessa entrada no IEOT .
Basicamente, com índices V4, ele gera deslocamentos em blocos de entradas compactadas com prefixo.
Com a nova configuração de configuração index.threads , o carregamento do índice agora é mais rápido.
Como resultado ( do uso do IEOT ), confirme 7bd9631 para limpar a read-cache.c load_cache_entries_threaded()
função do Git 2.23 (terceiro trimestre de 2019).
Veja cometer 8373037 , cometer d713e88 , cometer d92349d , cometer 113c29a , cometer c95fc72 , cometer 7a2a721 , cometer c016579 , cometer be27fb7 , cometer 13a1781 , cometer 7bd9631 , cometer 3c1dce8 , cometer cf7a901 , cometer d64db5b , cometer 76a7bc0 (09 de maio de 2019) por Jeff King ( peff
) .
(Incorporado por Junio C Hamano - gitster
- in commit c0e78f7 , 13 jun 2019)
cache de leitura: elimina o parâmetro não utilizado da carga encadeada
A load_cache_entries_threaded()
função usa um src_offset
parâmetro que não usa. Isso existe desde a sua criação em 77ff112 ( read-cache
: carregar entradas de cache nos threads de trabalho, 10/10/2018, Git v2.20.0-rc0).
Ao pesquisar na lista de discussão, esse parâmetro fazia parte de uma iteração anterior da série , mas se tornou desnecessário quando o código passou a usar a extensão IEOT.