Où Git stocke-t-il le SHA1 du commit pour un sous-module ?

Question

Je sais que lorsqu'on ajoute un submodule à un dépôt git, il suit un commit particulier de ce submodule référencé par son sha1.

J'essaie de trouver où cette valeur sha1 est stockée.

En .gitmodules y .git/config ne montrent que les chemins du sous-module, mais pas le sha1 du commit.

En git-submodule(1) La référence ne parle que d'un gitlink et l'entrée gitmodules(5) La référence ne dit rien non plus à ce sujet.

Answer 1

Il est stocké directement dans la base de données d'objets de Git. L'objet arbre du répertoire où se trouve le sous-module aura une entrée pour le commit du sous-module (c'est ce qu'on appelle le "gitlink").

Essayez de faire git ls-tree master <path-to-directory-containing-submodule> (ou simplement git ls-tree master si le sous-module se trouve dans le répertoire de premier niveau).

Answer 2

En base de données d'objets ( $GIT_DIR/objects/ ) où est stocké l'objet arbre du sous-module, évolue récemment :

Avec Git 2.34 (Q4 2021), le code pour rendre " git grep " ( homme ) recurse into submodules a été mis à jour pour s'éloigner du mécanisme "add submodules object store as an alternate object store" (qui est sous-optimal).

Véase commit 18a2f66 , commit e3e8bf0 , engagement 0693806 , commit dd45471 , commit 78ca584 , commit 50d92b5 , commit 8d33c3a , commit a35e03d (16 août 2021) par Jonathan Tan ( jhowtan ) .
(fusionné par Junio C Hamano -- gitster -- en commit 11e5d0a , 20 Sep 2021)

submodule : ajouter paresseusement des ODB de sous-module comme substituts

Signé par : Jonathan Tan
Critique par : Emily Shaffer
Rédigé par : Matheus Tavares

Apprendre à Git à ajouter des ODB de sous-modules en remplacement du magasin d'objets de the_repository uniquement lors du premier accès d'un objet qui n'est pas en the_repository, et non pas lorsque add_submodule_odb() est appelé.

Cela permet de passer progressivement de l'accès à l'objet d'un sous-module par le biais d'alternatives à l'accès à l'objet d'un sous-module en transmettant explicitement son objet de dépôt.
Toute commande Git peut déclarer qu'elle est susceptible d'accéder aux objets du sous-module en appelant la commande add_submodule_odb() (comme c'est le cas actuellement), mais les ODB des sous-modules eux-mêmes ne seront ajoutés qu'en cas de besoin, de sorte que les commandes individuelles et/ou les combinaisons d'arguments peuvent être migrées une par une.

[L'avantage du passage explicite de l'objet au référentiel est la clarté du code (il est clair de quel référentiel provient un objet lu), la performance (il n'est pas nécessaire d'effectuer une recherche linéaire dans tous les ODB des sous-modules chaque fois qu'un objet est accédé à partir de n'importe quel référentiel, qu'il s'agisse d'un superprojet ou d'un sous-module), et la possibilité de fonctionnalités futures telles que les sous-modules de clonage partiel (ce qui n'est pas possible à l'heure actuelle car si un objet est manquant, nous ne savons pas dans quel référentiel effectuer une recherche paresseuse)].

Ce commit introduit également une variable d'environnement qu'un test peut définir pour rendre fatal l'enregistrement des alternatives, afin de démontrer que ses chemins de code n'ont pas besoin de cet enregistrement.