Comment mettre à jour uniquement des sous-modules git spécifiques ?

Question

Ainsi, la mise à jour de tous mes sous-modules se fait en lançant

git submodule foreach 'git pull origin master'

Comment mettre à jour un sous-module spécifique , situé dans le pays suivant bundle/syntastic sans mettre à jour d'autres sous-modules ?

Answer 1

J'y arrive en cherchant comment mettre à jour un submodule spécifique uniquement, ce qui signifie pour moi, mettre à jour un submodule vers la ref pointée par sa super-repo. Ce qui n'est ni la question ni la réponse mais seulement le titre.

Ainsi, dans l'espoir d'aider d'autres personnes comme moi, la réponse au titre de la question est la suivante :

git submodule update <specific path to submodule>

ce qui mettra ce sous-module dans l'état de la ref commitée dans la super-repo.

Answer 2

En fait, la syntaxe correcte est la suivante

$ git clone <remote.git>
$ cd <remote>
$ git submodule update --init -- <specific relative path to submodule>

Answer 3

A partir de la documentation du sous-module git

--remote Cette option n'est valable que pour la commande update. Au lieu d'utiliser le SHA-1 enregistré par le superprojet pour mettre à jour le sous-module, utilisez la commande de la branche de suivi à distance du sous-module. Le remote utilisé est de la branche (branch..remote), la valeur par défaut étant l'origine.

Pour mettre à jour un sous-module spécifique, vous pouvez utiliser :

git submodule update --remote <path to the submodule>

Dans votre cas, il s'agit de :

git submodule update --remote bundle/syntastic

Answer 4

Si vous venez de cloner un repo avec des sous-modules, vous pouvez cloner un sous-module spécifique avec :

git submodule update --init submoduleName

Cela clonera le master de ce sous-module, à partir duquel vous pourrez cd dans le sous-module et tirer toutes les branches dont vous avez besoin.

Answer 5

Comment mettre à jour un sous-module spécifique, situé par exemple dans bundle/syntastic sans mettre à jour d'autres sous-modules ?

Avec Git 2.13 (et l'aide de submodule.<name>.update réglage de la configuration ):

git clone --recurse-submodules="bundle/syntastic"
git config submodule.syntastic.update "git pull origin master"

La deuxième ligne (à n'exécuter qu'une seule fois) est nécessaire parce que la fonction clone --recurse-submodules[=<pathspec] La commande est équivalente à l'exécution de la commande git submodule update --init --recursive <pathspec> immédiatement après la fin du clonage.
Et cela ne ferait que vérifier le sous-module à son gitlink enregistré SHA1, no au plus tard à distance origin/master SHA1.
En ajoutant le submodule.<name>.update réglage de la configuration vous vous assurez que le clone sélectif du sous-module sera suivi d'une mise à jour, uniquement pour ce sous-module.

---

Dans le cadre de la fonctionnalité "active submodule" de Git 2.13 (Q2 2017) (voir " Ignorer les nouveaux commits pour git submodule "), on obtient ceci commit bb62e0a de Brandon Williams ( bmwill ) :

clone : enseigner --recurse-submodules pour prendre optionnellement un chemin d'accès

Enseigner le clone --recurse-submodules pour prendre éventuellement un chemin qui décrit les sous-modules à initialiser et à cloner récursivement. clonés.
Si aucun chemin d'accès n'est fourni, --recurse-submodules initialisera et clonera récursivement tous les sous-modules en utilisant un chemin d'accès par défaut de " . ".
Afin de construire des spécifications de chemin plus complexes, --recurse-submodules peut être donné plusieurs fois.

Cela permet également de configurer l'option ' submodule.active ' configuratio la spécification de chemin donnée, de sorte que toute invocation future de l'option de configuration git submodule update suivra l'évolution de la situation.

En outre, le commutateur ' --recurse ' est supprimée du ainsi que caché dans le tableau des options, afin de simplifier les options pour les sous-modules. pour les sous-modules. Un simple ' --recurse n'indique pas ce qui est récurrent, par exemple par exemple, il peut s'agir de répertoires ou d'arbres (cf. ls-tree ).
Dans beaucoup d'autres commandes, nous avons déjà ' --recurse-submodules pour signifier récursivité dans les sous-modules, et annonce donc ici cette orthographe comme la véritable option.

Ainsi, le git clone --recursive page de manuel se lit désormais comme suit :

--recurse-submodules[=<pathspec]:

Une fois le clone créé, initialiser et cloner les sous-modules qui s'y trouvent en fonction des spécifications de chemin fournies. .

Si aucun chemin n'est fourni, tous les sous-modules sont initialisés et clonés.

Les sous-modules sont initialisés et clonés en utilisant leurs paramètres par défaut.
Le clone qui en résulte a submodule.active au chemin d'accès fourni, ou " . "(c'est-à-dire tous les sous-modules) si aucun chemin n'est fourni.
Cela équivaut à exécuter git submodule update --init --recursive immédiatement après la fin du clonage. Cette option est ignorée si le n'a pas d'arbre de travail/de sortie (c.-à-d. --no-checkout / -n , --bare ou --mirror est donnée)

Exemple de la t/t7400-submodule-basic.sh test :

git clone --recurse-submodules="." \
          --recurse-submodules=":(exclude)sub0" \
          --recurse-submodules=":(exclude)sub2" \
          multisuper multisuper_clone

Cela clonerait et mettrait à jour tous les sous-modules, à l'exception de sub0 y sub2 .

---

Bonus, avec Git 2.22 (Q2 2019) " git clone --recurs "fonctionne mieux.

Voir commit 5c38742 (29 avril 2019) par Nguyễn Thái Ngọc Duy ( pclouds ) .
(fusionné par Junio C Hamano -- gitster -- en commit 2cfab60 19 mai 2019)

parse-options : ne pas émettre d'"option ambiguë" pour les alias

Modifier le mécanisme d'analyse des options de manière à ce que, par exemple, " clone --recurs ... " ne provoque pas d'erreur parce que " clone "comprend à la fois " --recursive "et " --recurse-submodules "pour signifier la même chose.

Initialement, "clone" a été compris - unti récursif --recurses-submodules a été ajouté dans ccdd3da (" clone : A --recurse-submodules comme alias de l'option --recursive ", 2010-11-04, Git v1.7.4-rc0).
Depuis bb62e0a (" clone : enseigner --recurse-submodules t optionnellement un chemin", 2017-03-17, Git v2.13.0-rc0) la forme longue a été modifiée. promue à la valeur par défaut.

Mais en raison de la manière dont la machine d'analyse des options dans la situation plutôt absurde de :

$ git clone --recurs [...]
error: ambiguous option: recurs (could be --recursive or --recurse-submodules)

Ajouter OPT_ALIAS() pour exprimer ce lien entre deux ou plusieurs options et utiliser dans git-clone.