¿Qué hace el índice git contener exactamente?

https://stackoverflow.com/questions/4084921

git
internal

28-09-2019
|

Pregunta

¿Qué significa el índice de Git contiene exactamente, y qué comando se puede utilizar para ver el contenido del índice?

Actualizar

Gracias por todas sus respuestas. Yo sé que el índice actúa como zona de espera, y lo que se ha comprometido está en el índice en lugar del árbol de trabajo. Tengo curiosidad acerca de lo que un objeto índice se compone de. Supongo que podría ser una lista de nombre de archivo de nombre / directorio, SHA-1 pares, una especie de árbol virtual tal vez?

¿Hay, en la terminología de Git, cualquier plomería de comandos que puede utilizar para mostrar el contenido del índice?

Solución

El libro Git contiene un artículo sobre lo que incluye un índice :

El índice es un archivo binario (generalmente mantenido en .git/index) que contiene una lista ordenada de nombres de ruta, cada uno con permisos y la SHA1 de un objeto blob; git ls-files le puede mostrar el contenido del índice:

$ git ls-files --stage
100644 63c918c667fa005ff12ad89437f2fdc80926e21c 0   .gitignore
100644 5529b198e8d14decbe4ad99db3f7fb632de0439d 0   .mailmap

El Racy git problema da algunos detalles más sobre esa estructura:

El índice es una de las más importantes estructuras de datos en git.
  Representa un estado del árbol de trabajo virtual por lista de rutas y sus nombres de objeto a grabar y sirve como zona de espera para escribir el siguiente objeto árbol que estar comprometidos.
  El estado es "virtual" en el sentido de que no tiene por qué, y con frecuencia no es así, que coincida con los archivos en el directorio de trabajo.

Para ver más, cf. " git / git / Documentación / técnica / index -format.txt ":

El archivo de índice Git tiene el siguiente formato

Todos los números binarios están en orden de bytes de red.
   Versión 2 que se describe aquí a no ser que se indique lo contrario.


Una cabecera de 12 bytes que consiste en:

4 bytes firma :
  La firma es { 'D', 'I', 'R', 'C'} (siglas de " dircache ")

4 bytes número de versión :
  Las versiones actuales apoyado son 2, 3 y 4.

número de 32 bits de entradas de índice.



Un número de ordenados índice entradas .

Extensiones :
  Las extensiones se identifican por la firma.
  extensiones opcionales pueden ser ignorados si Git no los entiende.
  Actualmente Git compatible con las extensiones de árboles de deshacer y resolver en caché.
  extensión de la firma
4 bytes. Si el primer byte es 'A' .. 'Z' la extensión es opcional y se puede omitir.

tamaño de 32 bits de la extensión

Los datos de extensión



160 bits SHA-1 sobre el contenido del archivo de índice antes de que esta suma de comprobación.

mljrg comentarios :

Si el índice es el lugar donde el próximo commit es preparado, ¿por qué no retorno "git ls-files -s" nada después cometió?

Debido a que El índice representa lo que se está realizando un seguimiento , y justo después de una confirmación, lo que está siendo rastreado es idéntica a la última confirmación (retornos git diff --cached nada).

listas git ls-files -s Así que todos los archivos de seguimiento (nombre del objeto, bits de modo y número de etapas en la salida).

La lista (de elemento de seguimiento) se inicializa con el contenido de una confirmación.
Al cambiar de rama, el contenido del índice se restablece al commit que hace referencia la rama que acaba de seleccionar.

2,20 Git (Q4 2018) añade un tabla de índice de entrada de compensación (IEOT)

cometer 77ff112 , cometer 3.255.089 , cometer abb4bb8 , cometer c780b9c , cometer 3b1d9e0 , cometer 371ed0d (10 Oct 2018) por Ben Peart (benpeart) .
Ver cometer 252d079 (26 Sep 2018) por Nguyen Thai Ng?c Duy (pclouds) .
^{(fusionada por Junio ??C Hamano - gitster - en cometer e27bfaa 19 Oct 2018)}

ieot: añadir entrada de índice Offset Table (IEOT) de extensión

Este parche permite abordar el costo de CPU de cargar el índice mediante la adición   datos adicionales al índice que nos permitirá de manera eficiente múltiples   enhebrar la carga y conversión de entradas de caché.

Esto se logra mediante la adición de un (opcional) extensión de índice que es una   tabla de compensaciones a los bloques de entradas de caché en el archivo de índice.

Para hacer este trabajo para los índices V4, al escribir las entradas de caché, de manera periódica "reajusta" el prefijo-compresión mediante la codificación de la entrada actual, como si el nombre de ruta de la entrada anterior es completamente diferente y guarda el   desplazamiento de que la entrada en el IEOT.
  Básicamente, con índices V4, que genera desplazamientos en bloques de entradas prefijo-comprimido.

Con las nuevas index.threads config configuración , la carga índice es ahora más rápido.

Como resultado ( de utilizar IEOT ), cometer 7bd9631 limpieza de la función read-cache.c load_cache_entries_threaded() para Git 2,23 (Q3 2019).

cometer 8373037 , comprometerse d713e88 , comprometen d92349d , cometer 113c29a , cometer c95fc72 , cometer 7a2a721 , cometer c016579 , cometer be27fb7 , cometer 13a1781 , cometer 7bd9631 , cometer 3c1dce8 , cometer cf7a901 , commit d64db5b , cometer 76a7bc0 (09 de mayo de 2019) por Jeff king (peff) .
^{(fusionada por Junio ??C Hamano - gitster - en cometer c0e78f7 , 13 Jun 2019)}

leer-cache: soltar parámetro no utilizado de carga roscado

La función load_cache_entries_threaded() toma un parámetro src_offset   que no utiliza. Esto ha estado allí desde su creación en 77ff112 (read-cache: entradas de caché de carga en los subprocesos de trabajo, 10/10/2018, Git v2.20.0-RC0).

Excavar en la lista de correo, ese parámetro fue parte de una anteriormente iteración de la serie , pero se hizo innecesaria cuando el código pasado a utilizar la extensión IEOT.

Otros consejos

Bit por análisis de bit

he decidido hacer una pequeña prueba para comprender mejor el formato y la investigación de algunos de los campos con más detalle.

Resultados de abajo son las mismas para las versiones Git 1.8.5.2 y 2.3.

He marcado puntos que no estoy seguro / he que no se encuentran con TODO:. No dude en complementar esos puntos

Como otros han mencionado, el índice se almacena bajo .git/index, no como un objeto árbol estándar, y su formato es binario y se documenta en: https://github.com/git/git/blob/master/Documentation/technical/index-format.txt

Las principales estructuras que definen el índice son en cache.h , debido a que el índice es una memoria caché para la creación de confirmaciones.

Configuración

Cuando empezamos un repositorio de prueba con:

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

Las miradas de directorio .git como:

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

Y si conseguimos el contenido del único objeto:

git cat-file -p 78981922613b2afb6025042ff6bd878ac1994e85

Nos a. Esto indica que:

los puntos index a los contenidos de los archivos, ya que git add b crea un objeto blob
que almacena los metadatos en el archivo de índice, no en un objeto árbol, ya que sólo había un único objeto: la burbuja (en objetos normales Git, metadatos BLOB se almacena en el árbol)

hd análisis

Ahora vamos a ver el propio índice:

hd .git/index

Da:

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 continuación concluimos:

  | 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
  | ...                                                       |

Primero viene la cabecera, que se define en: estructura cache_header :

44 49 52 43: DIRC. TODO: ¿por qué es esto necesario
00 00 00 02: versión del formato: 2. El formato de índice ha evolucionado con el tiempo. Actualmente existe la versión hasta 4. El formato del índice no debe ser un problema cuando la colaboración entre diferentes ordenadores en GitHub porque repositorios desnudos no almacenan el índice:. Que se genera en el momento clon
00 00 00 01: recuento de archivos en el índice:. Sólo uno, b

A continuación se inicia una lista de entradas de índice, definida por estructura cache_entry Aquí tenemos uno solo. Contiene:

un montón de metadatos del archivo: 8 byte ctime, 8 byte mtime, a continuación, 4 byte:. Dispositivo, inode, modo, UID y GID

Nota cómo:
- ctime y mtime son los mismos (54 09 76 e6 1d 81 6f c6) como se esperaba ya que no hemos modificado el archivo
  
  Los primeros bytes son segundos desde EPOCH en hexadecimal:
```
date --date="@$(printf "%x" "540976e6")"
```
  Da:
```
Fri Sep  5 10:40:06 CEST 2014
```
  ¿Cuál es cuando hice este ejemplo.
  
  Los segundos 4 bytes son nanosegundos.
- UID y GID son 00 00 03 e8, 1000 en hexadecimal: un valor común para las configuraciones de usuario individuales
Todo esto metadatos, la mayoría de los cuales no está presente en objetos de árbol, permite Git para comprobar si un archivo ha cambiado rápidamente sin comparar el contenido.
al principio de 30 línea: tamaño de archivo:: 00 00 00 02 2 bytes (a y \n de echo)
78 98 19 22 ... c1 99 4e 85: 20 byte SHA-1 sobre el contenido anterior de la entrada. Tenga en cuenta que de acuerdo con la mis experimentos con la bandera válida asumen , las banderas que le siguen no se consideran en este SHA-1.
2 bytes flags: 00 01
- 1 bit: asumir la bandera de validez. Mis investigaciones indican que esta bandera mal llamada es donde git update-index --assume-unchanged almacena su estado: https://stackoverflow.com/a/28657085/895245
- 1 bit de bandera extendida. Determina si las banderas extendidas están presentes o no. Debe ser 0 en la versión 2, que no se han extendido banderas.
- bandera etapa
  2 bits utilizado durante la fusión. Las etapas se documentan en man git-merge:
  - 0: archivo normal, no en un conflicto de combinación
  - 1: Base
  - 2: nuestro
  - 3: el suyo
  Durante un conflicto de combinación, todas las etapas de 1-3 se almacenan en el índice para permitir operaciones como git checkout --ours.
  
  Si git add, a continuación, una etapa 0 se añade al índice para el camino, Git y sabrá que el conflicto se ha marcado como resuelto. TODO:. Comprobarlo
- 12 longitud de bits de la trayectoria que va a seguir: 0 01: 1 byte solamente desde el camino era b
2 bytes extendió banderas. Sólo tiene sentido si la "bandera extendida" se estableció en las banderas básicas. TODO.
62 (b ASCII): ruta de longitud variable. Longitud determinada en los pabellones anteriores, aquí sólo 1 byte, b.

A continuación, viene una 00: 1-8 bytes de relleno cero de modo que el camino será terminada en nulo y el índice terminará en un múltiplo de 8 bytes. Esto sólo ocurre antes índice de la versión 4.

Se utilizaron

No hay extensiones. Git sabe porque no habría espacio suficiente en el archivo de la suma de comprobación.

Finalmente hay una suma de comprobación ee 33 c0 3a .. 09 ab 49 94 20 byte sobre el contenido del índice.

El índice de Git es un área de ensayo entre su directorio de trabajo y su repositorio. Puede utilizar el índice para construir un conjunto de cambios que desea comprometerse juntos. Cuando se crea una confirmación, lo que se ha comprometido es lo que se encuentra actualmente en este índice, no lo es en su directorio de trabajo.

Para ver lo que hay dentro del índice, ejecute el comando:

git status

Al ejecutar git status, se puede ver qué archivos están en escena (en la actualidad en el índice), que están modificados pero aún no puesta en escena, y que son completamente sin seguimiento.

Usted puede leer esta . Una búsqueda en Google arroja muchos enlaces, que debe ser bastante autosuficiente.

Esto es lo que exactamente es necesario, utilice este comando.

$ binwalk índice

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

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow