Ajouter le dépôt donné comme sous-module au chemin donné vers les modifications à valider à côté du projet en cours : le projet en cours est appelé « superprojet ».

Afficher le statut des sous-modules. Cela affichera le SHA-1 du commit actuellement extrait pour chaque sous-module, ainsi que le chemin du sous-module et la sortie de git describe pour le SHA-1. Chaque SHA-1 sera éventuellement préfixé par - si le sous-module n’est pas initialisé, + si le commit du sous-module actuellement extrait ne correspond pas au SHA-1 trouvé dans l’index du dépôt contenant et U si le sous-module a des conflits de fusion.

Initialiser les sous-modules enregistrés dans l’index (qui ont été ajoutés et validés ailleurs) en définissant submodule.$nom.url dans .git/config, en utilisant le même paramètre de .gitmodules comme modèle. Si l’URL est relative, elle sera résolue en utilisant le distant par défaut. S’il n’y a pas de distant par défaut, le dépôt actuel sera supposé être en amont.

Désenregistrez les sous-modules donnés, c’est-à-dire supprimez toute la section submodule.$name de .git/config ainsi que leur arborescence de travail. Les appels ultérieurs à git submodule update, git submodule foreach et git submodule sync ignoreront tous les sous-modules non enregistrés jusqu’à ce qu’ils soient initialisés à nouveau, donc utilisez cette commande si vous ne voulez plus avoir de vérification locale du sous-module dans votre arbre de travail.

Définir la branche distante par défaut pour le sous-module. L’option --branch permet de spécifier la branche distante. L’option --default supprime la clé de configuration submodule.<nom>.branch, ce qui fait que la branche de suivi par défaut est la branche HEAD distante .

Fixer l’URL du sous-module spécifié à <nouvelle-url>. Ensuite, il synchronisera automatiquement la nouvelle configuration de l’URL distante du sous-module.

Afficher le résumé du commit entre le commit donné (par défaut HEAD) et l’arbre de travail/index. Pour un sous-module en question, une série de commits dans le sous-module entre le commit donné du super projet et l’index ou l’arbre de travail (commuté par --cached) sont affichés. Si l’option --files est donnée, afficher la série de commits dans le sous-module entre l’index du super projet et l’arbre de travail du sous-module (cette option ne permet pas d’utiliser l’option --cached ou de fournir un commit explicite).

Évaluer une commande shell arbitraire dans chaque sous-module extrait. La commande a accès aux variables $name, $sm_path, $displaypath, $sha1 et $toplevel : $name est le nom de la section du sous-module concernée dans .gitmodules, $sm_path est le chemin du sous-module tel qu’il est enregistré dans le superprojet immédiat, $displaypath contient le chemin relatif du répertoire de travail courant au répertoire racine du sous-modules, $sha1 est le commit tel qu’il est enregistré dans le superprojet immédiat, et $toplevel est le chemin absolu vers le niveau supérieur du superprojet immédiat. Notez que pour éviter les conflits avec $PATH sous Windows, la variable $path est maintenant un synonyme obsolète de la variable $sm_path. Tous les sous-modules définis dans le superprojet mais non extraits sont ignorés par cette commande. A moins qu’on ne lui donne --quiet, foreach imprime le nom de chaque sous-module avant d’évaluer la commande. Si la variable --recursive est donnée, les sous-modules sont parcourus de manière récursive (c’est-à-dire que la commande shell donnée est également évaluée dans les sous-modules imbriqués). Un retour non nul de la commande dans un sous-module quelconque entraîne l’arrêt du traitement. Il est possible d’y remédier en ajoutant || : à la fin de la commande.

git submodule foreach 'echo $sm_path `git rev-parse HEAD`'

Synchroniser le paramètre de configuration de l’URL distante des sous-modules à la valeur spécifiée dans .gitmodules. Cela n’affectera que les sous-modules qui ont déjà une entrée d’URL dans .git/config (c’est le cas lorsqu’ils sont initialisés ou fraîchement ajoutés). Ceci est utile lorsque les URL des sous-modules changent en amont et que vous devez mettre à jour vos dépôts locaux en conséquence.

Si un répertoire git d’un sous-module se trouve à l’intérieur du sous-module, déplacer le répertoire git du sous-module dans le chemin $GIT_DIR/modules de son superprojet, puis connecter le répertoire git et son répertoire de travail en définissant le core.worktree et en ajoutant un fichier .git pointant sur le répertoire git intégré dans le répertoire git du superprojet.

N’afficher que les messages d’erreur.

Cette option n’est valide que pour les commandes add et update. L’état d’avancement est affiché sur la sortie d’erreur standard par défaut quand elle est attachée à un terminal, à moins que -q soit spécifié. Ce drapeau force l’état d’avancement même si le flux d’erreur standard n’est pas dirigé vers un terminal.

Cette option n’est valide que pour la commande deinit. Désenregistrer tous les sous-modules dans l’arbre de travail.

Branche du dépôt à ajouter comme sous-module. Le nom de la branche est enregistré comme submodule.<nom>.branch dans .gitmodules pour update--remote. Une valeur spéciale de . est utilisée pour indiquer que le nom de la branche dans le sous-module doit être le même que celui de la branche active dans le dépôt actuel. Si l’option n’est pas spécifiée, la valeur par défaut est HEAD distant.

Cette option n’est valable que pour les commandes add, deinit et update. Lors de l’exécution de la commande add, autorisez l’ajout d’un chemin de sous-module autrement ignoré. Lors de l’exécution de deinit, les arbres de travail des sous-module seront supprimés même s’ils contiennent des modifications locales. Lors de l’exécution de update (uniquement active avec la procédure de checkout), jeter les modifications locales dans les sous-module lors du passage à un commit différent ; et toujours exécuter une opération d’extraction dans le sous-module, même si le commit listé dans l’index du dépôt le contenant correspond au commit extrait dans le sous-module.

Cette option n’est valide que pour les commandes d’état et de résumé. Ces commandes utilisent généralement le commit trouvé dans la HEAD du sous-module, mais avec cette option, le commit stocké dans l’index est utilisé à la place.

Cette option n’est valable que pour la commande summary. Cette commande compare le commit dans l’index avec celui du sous-module HEAD lorsque cette option est utilisée.

Cette option n’est valable que pour la commande summary. Limiter la taille du résumé (nombre de validations affichées au total). Donner 0 désactivera le résumé ; un nombre négatif signifie illimité (par défaut). Cette limite ne s’applique qu’aux sous-modules modifiés. La taille est toujours limitée à 1 pour les sous-modules ajoutés/supprimés/modifiés.

Cette option n’est valable que pour la commande de mise à jour. Au lieu d’utiliser le SHA-1 enregistrée du superprojet pour mettre à jour le sous-module, utiliser le statut de la branche de suivi à distance du sous-module. Le distant utilisé est le distant de la branche (branch.<nom>.remote), dont la valeur par défaut est origin. La branche distante utilisée est par défaut la branche distante HEAD, mais le nom de la branche peut être remplacé par l’option submodule.<nom>.branch dans .gitmodules ou .git/config (avec .git/config en priorité).

Cette option n’est valable que pour la commande update. Ne pas récupérer de nouveaux objets sur le site distant.

Cette option n’est valable que pour la commande update. Vérifier le commit enregistré dans le superprojet sur une HEAD détachée dans le sous-module. C’est le comportement par défaut, l’utilisation principale de cette option est de remplacer submodule.$nom.update lorsqu’elle est définie à une valeur autre que checkout. Si la clé submodule.$nom.update n’est pas explicitement définie ou est définie à checkout, cette option est implicite.

Cette option n’est valable que pour la commande update. Fusionner le commit enregistré dans le superprojet dans la branche actuelle du sous-module. Si cette option est donnée, la HEAD du sous-module ne sera pas détachée. Si un échec de fusion empêche ce processus, vous devrez résoudre les conflits résultants au sein du sous-module avec les outils de résolution de conflits habituels. Si la clé submodule.$nom.update est définie sur fusion, cette option est implicite.

Cette option n’est valable que pour la commande de mise à jour. Rebaser la branche actuelle sur le commit enregistré dans le superprojet. Si cette option est donnée, la HEAD du sous-module ne sera pas détachée. Si un échec de fusion empêche ce processus, vous devrez résoudre ces échecs avec git-rebase[1]. Si la clé submodule.$nom.update est définie sur rebase, cette option est implicite.

Cette option n’est valable que pour la commande update. Initialiser tous les sous-modules pour lesquels "git submodule init" n’a pas été appelé jusqu’à présent avant la mise à jour.

Cette option n’est valable que pour la commande add. Elle fixe le nom du sous-module à la chaîne de caractères donnée au lieu de choisir par défaut son chemin d’accès. Le nom doit être valide en tant que nom de répertoire et ne peut pas se terminer par un "/".

Cette option n’est valable que pour les commandes add et update. Ces commandes ont parfois besoin de cloner un dépôt distant. Dans ce cas, cette option sera passée à la commande git-clone[1].

Cette option n’est valable que pour les commandes add et update. Ces commandes ont parfois besoin de cloner un dépôt distant. Dans ce cas, cette option sera passée à la commande git-clone[1].

Cette option n’est valable que pour les commandes foreach, update, status et sync. Traverser les sous-modules de façon récursive. L’opération est effectuée non seulement dans les sous-modules du dépôt actuel, mais aussi dans tous les sous-modules imbriqués à l’intérieur de ces sous-modules (et ainsi de suite).

Cette option est valable pour les commandes d’ajout et de mise à jour. Créer un clone superficiel avec un historique tronqué au nombre de révisions spécifié. Voir git-clone[1]

Cette option n’est valable que pour la commande de mise à jour. Le clone initial d’un sous-module utilisera le submodule.<nom>.shallow recommandé, tel que fourni par le fichier .gitmodules par défaut. Pour ignorer les suggestions, utilisez --no-recommend-shallow.

Cette option n’est valable que pour la commande update. Cloner les nouveaux sous-modules en parallèle avec autant de tâches. L’option submodule.fetchJobs est utilisée par défaut.

Cette option n’est valable que pour la commande update. Cloner une seule branche pendant la mise à jour : HEAD ou une branche spécifiée par --branch.

Chemins vers le(s) sous-module(s). Lorsque cela est spécifié, la commande ne fonctionnera que sur les sous-modules se trouvant sur les chemins spécifiés. (Cet argument est requis avec add).