O que o índice git contém EXATAMENTE?

O que o índice Git contém exatamente e qual comando posso usar para visualizar o conteúdo do índice?

Atualizar

Obrigado por todas as suas respostas. Eu sei que o índice atua como uma área de preparação, e o que está comprometido está no índice e não na árvore de trabalho. Estou apenas curioso sobre o que consiste um objeto de índice. Eu acho que pode ser uma lista de nome de arquivo / diretório, pares SHA-1, uma espécie de árvore virtual, talvez?

Existe, na terminologia Git, algum comando de canalização que eu possa usar para listar o conteúdo do índice?

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-filespode 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 --cachednão retorna nada).

Então, git ls-files -slista 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_offsetparâ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.

Análise bit a bit

Decidi fazer um pequeno teste para entender melhor o formato e pesquisar alguns dos campos com mais detalhes.

Os resultados abaixo são os mesmos para as versões Git 1.8.5.2e 2.3.

Marquei pontos com os quais não tenho certeza / não encontrei TODO: fique à vontade para complementar esses pontos.

Como outros mencionados, o índice é armazenado em .git/index, não como um objeto de árvore padrão, e seu formato é binário e documentado em: https://github.com/git/git/git/blob/master/Documentation/technical/index-format. TXT

As principais estruturas que definem o índice estão em cache.h , porque o índice é um cache para a criação de confirmações.

Configuração

Quando iniciamos um repositório de teste com:

git init
echo a > b
git add b
tree --charset=ascii

O .gitdiretório se parece com:

.git/objects/
|-- 78
|   `-- 981922613b2afb6025042ff6bd878ac1994e85
|-- info
`-- pack

E se obtivermos o conteúdo do único objeto:

git cat-file -p 78981922613b2afb6025042ff6bd878ac1994e85

Nós recebemos a. Isso indica que:

• os indexpontos para o conteúdo do arquivo, pois git add bcriou um objeto blob
• ele armazena os metadados no arquivo de índice, não em um objeto em árvore, pois havia apenas um único objeto: o blob (em objetos Git regulares, os metadados em blob são armazenados na árvore)

análise hd

Agora vamos ver o próprio índice:

hd .git/index

Dá:

00000000  44 49 52 43 00 00 00 02  00 00 00 01 54 09 76 e6  |DIRC.... ....T.v.|
00000010  1d 81 6f c6 54 09 76 e6  1d 81 6f c6 00 00 08 05  |..o.T.v. ..o.....|
00000020  00 e4 2e 76 00 00 81 a4  00 00 03 e8 00 00 03 e8  |...v.... ........|
00000030  00 00 00 02 78 98 19 22  61 3b 2a fb 60 25 04 2f  |....x.." a;*.`%./|
00000040  f6 bd 87 8a c1 99 4e 85  00 01 62 00 ee 33 c0 3a  |......N. ..b..3.:|
00000050  be 41 4b 1f d7 1d 33 a9  da d4 93 9a 09 ab 49 94  |.AK...3. ......I.|
00000060

A seguir, concluiremos:

  | 0           | 4            | 8           | C              |
  |-------------|--------------|-------------|----------------|
0 | DIRC        | Version      | File count  | ctime       ...| 0
  | ...         | mtime                      | device         |
2 | inode       | mode         | UID         | GID            | 2
  | File size   | Entry SHA-1                              ...|
4 | ...                        | Flags       | Index SHA-1 ...| 4
  | ...                                                       |

Primeiro vem o cabeçalho, definido em: struct cache_header :

• 44 49 52 43: DIRC. TODO: por que isso é necessário?

• 00 00 00 02: format version: 2. O formato do índice evoluiu com o tempo. Atualmente, existe uma versão até 4. O formato do índice não deve ser um problema ao colaborar entre computadores diferentes no GitHub, porque repositórios vazios não armazenam o índice: ele é gerado no momento do clone.

• 00 00 00 01: contagem de arquivos no índice: apenas um b,.

Em seguida, inicia uma lista de entradas de índice, definidas por struct cache_entry Aqui temos apenas uma. Contém:

• vários metadados de arquivo: 8 bytes ctime, 8 bytes mtimee 4 bytes: dispositivo, inode, modo, UID e GID.

  Observe como:

  • ctimee mtimesão os mesmos ( 54 09 76 e6 1d 81 6f c6) esperados, pois não modificamos o arquivo

    Os primeiros bytes são segundos desde EPOCH em hexadecimal:

    date --date="@$(printf "%x" "540976e6")"
    

    Dá:

    Fri Sep  5 10:40:06 CEST 2014
    

    Foi quando eu fiz esse exemplo.

    Os segundos 4 bytes são nanossegundos.

  • UID e GID são 00 00 03 e81000 em hexadecimal: um valor comum para configurações de usuário único.

  Todos esses metadados, a maioria dos quais não está presente nos objetos da árvore, permitem ao Git verificar se um arquivo mudou rapidamente sem comparar o conteúdo inteiro.

• no início da linha 30:: 00 00 00 02tamanho do arquivo: 2 bytes ( ae \nde echo)

• 78 98 19 22 ... c1 99 4e 85: 20 bytes SHA-1 sobre o conteúdo anterior da entrada. Observe que, de acordo com minhas experiências com o sinalizador assumido válido , os sinalizadores a seguir não são considerados neste SHA-1.

• Sinalizadores de 2 bytes: 00 01

  • 1 bit: assume sinalizador válido. Minhas investigações indicam que esse sinalizador com nomes inadequados é onde git update-index --assume-unchangedarmazena seu estado: https://stackoverflow.com/a/28657085/895245

  • Sinalizador estendido de 1 bit. Determina se os sinalizadores estendidos estão presentes ou não. Deve estar 0na versão 2 que não possui sinalizadores estendidos.

  • Sinalizador de estágio de 2 bits usado durante a mesclagem. As etapas estão documentadas em man git-merge:

    • 0: arquivo regular, não em conflito de mesclagem
    • 1: base
    • 2: nosso
    • 3: deles

    Durante um conflito de mesclagem, todos os estágios de 1 a 3 são armazenados no índice para permitir operações como git checkout --ours.

    Se você git add, um estágio 0 é adicionado ao índice do caminho, e o Git saberá que o conflito foi marcado como resolvido. TODO: verifique isso.

  • Comprimento de 12 bits do caminho a seguir 0 01:: 1 byte somente desde que o caminho foib

• Sinalizadores estendidos de 2 bytes. Somente significativo se o "sinalizador estendido" tiver sido definido nos sinalizadores básicos. FAÇAM.

• 62(ASCII b): caminho de comprimento variável. Comprimento determinado nos sinalizadores anteriores, aqui apenas 1 byte b,.

Em seguida, vem 00: 1-8 bytes de preenchimento zero, para que o caminho seja nulo e o índice termine em um múltiplo de 8 bytes. Isso acontece apenas antes da versão 4 do índice.

Nenhuma extensão foi usada. O Git sabe disso porque não haveria espaço suficiente no arquivo para a soma de verificação.

Finalmente, há uma soma de verificação de 20 bytes ee 33 c0 3a .. 09 ab 49 94sobre o conteúdo do índice.

O índice Git é uma área intermediária entre o diretório ativo e o repositório. Você pode usar o índice para criar um conjunto de alterações que deseja confirmar juntos. Quando você cria uma confirmação, o que é confirmado é o que está atualmente neste índice, não o que está no seu diretório de trabalho.

Para ver o que está dentro do índice, emita o comando:

git status

Ao executar o status do git, é possível ver quais arquivos estão preparados (atualmente no seu índice), quais foram modificados, mas ainda não estão preparados, e quais não estão completamente rastreados.

Você pode ler isso . Uma pesquisa no Google exibe muitos links, que devem ser bastante auto-suficientes.

Aqui está exatamente o que você precisava, use este comando.

$ binwalk index

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
1717          0x6B5           Unix path: /company/user/user/delete.php
1813          0x715           Unix path: /company/user/user/get.php
1909          0x775           Unix path: /company/user/user/post.php
2005          0x7D5           Unix path: /company/user/user/put.php
3373          0xD2D           Unix path: /urban-airship/channel/channel/post.php
3789          0xECD           Unix path: /urban-airship/named-user/named-user/post.php
3901          0xF3D           Unix path: /user/categories/categories/delete.php
4005          0xFA5           Unix path: /user/categories/categories/get.php
4109          0x100D          Unix path: /user/categories/categories/put.php
4309          0x10D5          Unix path: /user/favorites/favorites/delete.php

O índice Git é um arquivo binário (geralmente mantido em .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-filespode mostrar o conteúdo do índice. Por favor, note que as palavras index, stagee cachesão a mesma coisa em Git: eles são usados de forma intercambiável.

O índice Git, ou cache Git, possui três propriedades importantes:

1. O índice contém todas as informações necessárias para gerar um único objeto de árvore (determinado exclusivamente).
2. O índice permite comparações rápidas entre o objeto de árvore que define e a árvore de trabalho.
3. Ele pode representar com eficiência informações sobre conflitos de mesclagem entre diferentes objetos da árvore, permitindo que cada nome de caminho seja associado a informações suficientes sobre as árvores envolvidas, para que você possa criar uma mesclagem de três vias entre elas.

Fonte :

1. https://mincong.io/2018/04/28/git-index/
2. https://medium.com/hackernoon/understanding-git-index-4821a0765cf