Le livre Git contient un article sur ce qu'un index comprend :
L'index est un fichier binaire (généralement conservé .git/index) contenant une liste triée de noms de chemin, chacun avec des autorisations et le SHA1 d'un objet blob; git ls-filespeut vous montrer le contenu de l'index:
$ git ls-files --stage
100644 63c918c667fa005ff12ad89437f2fdc80926e21c 0 .gitignore
100644 5529b198e8d14decbe4ad99db3f7fb632de0439d 0 .mailmap
Le problème git Racy donne plus de détails sur cette structure:
L'index est l'une des structures de données les plus importantes de git.
Il représente un état d'arborescence de travail virtuel en enregistrant la liste des chemins et leurs noms d'objet et sert de zone de transit pour écrire le prochain objet d'arborescence à valider.
L'état est "virtuel" dans le sens où il ne doit pas nécessairement correspondre, et souvent pas, aux fichiers de l'arborescence de travail.
Pour en savoir plus, cf. " git / git / Documentation / technical / index-format.txt ":
Le fichier d'index Git a le format suivant
Tous les nombres binaires sont dans l'ordre des octets du réseau. Sauf indication contraire, la
version 2 est décrite ici.
- Un en-tête de 12 octets composé de:
- Signature à 4 octets :
la signature est {' D', ' I', ' R', ' C'} (signifie " dircache")
- Numéro de version sur 4 octets :
les versions actuellement prises en charge sont 2, 3 et 4.
- Nombre d'entrées d'index de 32 bits.
- Un certain nombre d' entrées d'index triées .
- Extensions : les
extensions sont identifiées par signature.
Les extensions facultatives peuvent être ignorées si Git ne les comprend pas.
Git prend actuellement en charge l'arborescence mise en cache et résout les extensions d'annulation.
- Signature d'extension de 4 octets. Si le premier octet est «
A..» Z, l'extension est facultative et peut être ignorée.
- Taille 32 bits de l'extension
- Données d'extension
- SHA-1 160 bits sur le contenu du fichier d'index avant cette somme de contrôle.
commentaires mljrg :
Si l'index est l'endroit où le prochain commit est préparé, pourquoi " git ls-files -s" ne retourne-t-il rien après le commit?
Comme l'index représente ce qui est suivi , et juste après une validation, ce qui est suivi est identique à la dernière validation ( git diff --cachedne renvoie rien).
Répertorie donc git ls-files -stous les fichiers suivis (nom de l'objet, bits de mode et numéro d'étape dans la sortie).
Cette liste (des éléments suivis) est initialisée avec le contenu d'un commit.
Lorsque vous changez de branche, le contenu de l'index est réinitialisé au commit référencé par la branche vers laquelle vous venez de basculer.
Git 2.20 (Q4 2018) ajoute une table de décalage d'entrée d'index (IEOT) :
Voir commit 77ff112 , commit 3255089 , commit abb4bb8 , commit c780b9c , commit 3b1d9e0 , commit 371ed0d (10 octobre 2018) par Ben Peart ( benpeart) .
Voir commit 252d079 (26 septembre 2018) par Nguyễn Thái Ngọc Duy ( pclouds) .
(Fusionné par Junio C Hamano - gitster- dans commit e27bfaa , 19 oct 2018)
ieot: ajout de l'extension IEOT (Index Entry Offset Table)
Ce correctif permet de traiter le coût CPU du chargement de l'index en ajoutant des données supplémentaires à l'index qui nous permettront de multi-thread efficacement le chargement et la conversion des entrées de cache.
Il accomplit cela en ajoutant une extension d'index (facultative) qui est une table de décalages aux blocs d'entrées de cache dans le fichier d'index.
Pour que cela fonctionne pour les index V4, lors de l'écriture des entrées de cache, il "réinitialise" périodiquement la compression de préfixe en codant l'entrée actuelle comme si le nom de chemin de l'entrée précédente était complètement différent et enregistre le décalage de cette entrée dans l'IEOT .
Fondamentalement, avec les index V4, il génère des décalages en blocs d'entrées compressées par préfixe.
Avec le nouveau paramètre de configuration index.threads , le chargement de l'index est désormais plus rapide.
En conséquence ( de l'utilisation d'IEOT ), validez 7bd9631 pour nettoyer la read-cache.c load_cache_entries_threaded()fonction pour Git 2.23 (Q3 2019).
Voir le commit 8373037 , le commit d713e88 , le commit d92349d , le commit 113c29a , le commit c95fc72 , le commit 7a2a721 , le commit c016579 , le commit be27fb7 , le commit 13a1781 , le commit 7bd9631 , le commit 3c1dce8 , le commit cf7a901 , le commit d64db5b , le commit de Jeff Kingpeff (09 mai 2019) ( ) .
(Fusionné par Junio C Hamano - gitster- in commit c0e78f7 , 13 juin 2019)
read-cache: supprime le paramètre inutilisé de la charge threadée
La load_cache_entries_threaded()fonction prend un src_offsetparamètre qu'elle n'utilise pas. Cela existe depuis sa création dans 77ff112 ( read-cache: charger les entrées de cache sur les threads de travail, 10/10/2018, Git v2.20.0-rc0).
En creusant dans la liste de diffusion, ce paramètre faisait partie d'une itération antérieure de la série , mais est devenu inutile lorsque le code est passé à l'utilisation de l'extension IEOT.
