El libro de Git contiene un artículo sobre lo que incluye un índice :
El índice es un archivo binario (generalmente guardado .git/index) que contiene una lista ordenada de nombres de ruta, cada uno con permisos y el SHA1 de un objeto blob; git ls-filespuede mostrarle el contenido del índice:
$ git ls-files --stage
100644 63c918c667fa005ff12ad89437f2fdc80926e21c 0 .gitignore
100644 5529b198e8d14decbe4ad99db3f7fb632de0439d 0 .mailmap
El problema de Racy git da más detalles sobre esa estructura:
El índice es una de las estructuras de datos más importantes en git.
Representa un estado de árbol de trabajo virtual mediante el registro de la lista de rutas y sus nombres de objeto y sirve como un área de ensayo para escribir el siguiente objeto de árbol que se confirmará.
El estado es "virtual" en el sentido de que no necesariamente tiene que coincidir, y a menudo no coincide, con los archivos del árbol de trabajo.
Para ver más, cf. " git / git / Documentation / technical / index-format.txt ":
El archivo de índice de Git tiene el siguiente formato
Todos los números binarios están en orden de bytes de red.
La versión 2 se describe aquí a menos que se indique lo contrario.
- Un encabezado de 12 bytes que consta de:
- Firma de 4 bytes :
la firma es {' D', ' I', ' R', ' C'} (significa " dircache")
- Número de versión de 4 bytes :
las versiones compatibles actuales son 2, 3 y 4.
- Número de entradas de índice de 32 bits.
- Una serie de entradas de índice ordenadas .
- Extensiones : las
extensiones se identifican por firma.
Las extensiones opcionales pueden ignorarse si Git no las comprende.
Git actualmente admite árbol en caché y resuelve extensiones de deshacer.
- Firma de extensión de 4 bytes. Si el primer byte es '
A' .. ' Z', la extensión es opcional y puede ignorarse.
- Tamaño de 32 bits de la extensión
- Datos de extensión
- SHA-1 de 160 bits sobre el contenido del archivo de índice antes de esta suma de comprobación.
mljrg comenta :
Si el índice es el lugar donde se prepara la próxima confirmación, ¿por qué " git ls-files -s" no devuelve nada después de la confirmación?
Debido a que el índice representa lo que se está rastreando , y justo después de una confirmación, lo que se está rastreando es idéntico a la última confirmación ( git diff --cachedno devuelve nada).
Entonces, git ls-files -senumera todos los archivos rastreados (nombre del objeto, bits de modo y número de etapa en la salida).
Esa lista (de elemento rastreado) se inicializa con el contenido de una confirmación.
Cuando cambia de rama, el contenido del índice se restablece a la confirmación a la que hace referencia la rama a la que acaba de cambiar.
Git 2.20 (Q4 2018) agrega una tabla de compensación de entrada de índice (IEOT) :
Ver commit 77ff112 , commit 3255089 , commit abb4bb8 , commit c780b9c , commit 3b1d9e0 , commit 371ed0d (10 de octubre de 2018) por Ben Peart ( benpeart) .
Ver commit 252d079 (26 de septiembre de 2018) por Nguyễn Thái Ngọc Duy ( pclouds) .
(Fusionada por Junio C Hamano - gitster- en commit e27bfaa , 19 oct 2018)
ieot: agregar extensión de tabla de desplazamiento de entrada de índice (IEOT)
Este parche permite abordar el costo de la CPU de cargar el índice agregando datos adicionales al índice que nos permitirán realizar múltiples subprocesos de manera eficiente en la carga y conversión de entradas de caché.
Esto se logra al agregar una extensión de índice (opcional) que es una tabla de compensaciones a bloques de entradas de caché en el archivo de índice.
Para que esto funcione para los índices V4, al escribir las entradas de caché, periódicamente "restablece" la compresión de prefijos al codificar la entrada actual como si el nombre de ruta de la entrada anterior fuera completamente diferente y guardara el desplazamiento de esa entrada en el IEOT .
Básicamente, con los índices V4, genera compensaciones en bloques de entradas comprimidas con prefijo.
Con la nueva configuración de index.threads , la carga del índice ahora es más rápida.
Como resultado ( de usar IEOT ), confirme 7bd9631 limpia la read-cache.c load_cache_entries_threaded()función para Git 2.23 (Q3 2019).
Ver commit 8373037 , commit d713e88 , commit d92349d , commit 113c29a , commit c95fc72 , commit 7a2a721 , commit c016579 , commit be27fb7 , commit 13a1781 , commit 7bd9631 , commit 3c1dce8 , commit cf7a901 , commit d64db5b , commit 76a7b0 ( Jeffpeff May 09b ) ( ) .
(Fusionada por Junio C Hamano - gitster- en commit c0e78f7 , 13 jun 2019)
read-cache: descartar el parámetro no utilizado de la carga roscada
La load_cache_entries_threaded()función toma un src_offsetparámetro que no usa. Esto ha estado allí desde su inicio en 77ff112 ( read-cache: cargar entradas de caché en subprocesos de trabajo, 2018-10-10, Git v2.20.0-rc0).
Excavando en la lista de correo, ese parámetro era parte de una iteración anterior de la serie , pero se volvió innecesario cuando el código cambió para usar la extensión IEOT.
