Si je modifie un sous-module, puis-je repousser le commit à l'origine du sous-module, ou cela nécessiterait-il un clone? En cas de clonage, puis-je stocker un clone dans un autre référentiel?
Si je modifie un sous-module, puis-je repousser le commit à l'origine du sous-module, ou cela nécessiterait-il un clone? En cas de clonage, puis-je stocker un clone dans un autre référentiel?
Réponses:
Un sous-module n'est rien d'autre qu'un clone d'un dépôt git dans un autre dépôt avec des métadonnées supplémentaires (entrée d'arborescence gitlink, fichier .gitmodules)
$ cd your_submodule
$ git checkout master
<hack,edit>
$ git commit -a -m "commit in submodule"
$ git push
$ cd ..
$ git add your_submodule
$ git commit -m "Updated submodule"
gh-pages
branche pour la documentation sur un
Notez que depuis git1.7.11 ( [ANNONCE] Git 1.7.11.rc1 et note de publication , juin 2012) mentionne:
"
git push --recurse-submodules
" a appris à consulter éventuellement l'historique des sous-modules liés au superprojet et à les expulser.
Probablement fait après ce patch et l' --on-demand
option:
recurse-submodules=<check|on-demand>::
Assurez-vous que tous les commits de sous-module utilisés par les révisions à pousser sont disponibles sur une branche de suivi à distance.
- Si
check
est utilisé, il sera vérifié que tous les commits de sous-module qui ont changé dans les révisions à pousser sont disponibles sur une télécommande.
Sinon, le push sera abandonné et quittera avec un statut différent de zéro.- Si
on-demand
est utilisé, tous les sous-modules qui ont changé dans les révisions à pousser seront poussés.
Si à la demande n'était pas en mesure de pousser toutes les révisions nécessaires, il sera également abandonné et quittera avec un statut différent de zéro.
Ainsi, vous pouvez tout pousser en une seule fois avec (à partir du dépôt parent) a:
git push --recurse-submodules=on-demand
Cette option ne fonctionne que pour un seul niveau d'imbrication. Les modifications apportées au sous-module à l'intérieur d'un autre sous-module ne seront pas transmises.
Avec git 2.7 (janvier 2016), un simple push git suffira pour pousser le repo parent ... et tous ses sous-modules.
Voir commit d34141c , commit f5c7cd9 (3 décembre 2015), commit f5c7cd9 (3 décembre 2015) et commit b33a15b (17 novembre 2015) par Mike Crowe ( mikecrowe
) .
(Fusionné par Junio C Hamano - gitster
- in commit 5d35d72 , 21 déc 2015)
push
: ajouter unerecurseSubmodules
option de configurationLe
--recurse-submodules
paramètre de ligne de commande existe depuis un certain temps mais il n'a pas d'équivalent dans le fichier de configuration.En suivant le style du paramètre correspondant pour
git fetch
, inventonspush.recurseSubmodules
pour fournir une valeur par défaut pour ce paramètre.
Cela nécessite également l'ajout de--recurse-submodules=no
pour permettre à la configuration d'être remplacée sur la ligne de commande si nécessaire.Le moyen le plus simple d'implémenter cela semble être d'
push
utiliser le codesubmodule-config
de la même manière quefetch
.
La git config
doc comprend désormais :
push.recurseSubmodules
:Assurez-vous que tous les commits de sous-module utilisés par les révisions à pousser sont disponibles sur une branche de suivi à distance.
- Si la valeur est «
check
», alors Git vérifiera que tous les commits de sous-module qui ont changé dans les révisions à pousser sont disponibles sur au moins une télécommande du sous-module. Si des validations sont manquantes, le push sera abandonné et se terminera avec un statut différent de zéro.- Si la valeur est «
on-demand
», tous les sous-modules qui ont changé dans les révisions à pousser seront poussés. Si à la demande n'était pas en mesure de pousser toutes les révisions nécessaires, il sera également abandonné et quittera avec un statut différent de zéro. -- Si la valeur est «
no
», le comportement par défaut consistant à ignorer les sous-modules lors de la poussée est conservé.Vous pouvez remplacer cette configuration au moment de l'envoi en spécifiant «
--recurse-submodules=check|on-demand|no
».
Alors:
git config push.recurseSubmodules on-demand
git push
Git 2.12 (1er trimestre 2017)
git push --dry-run --recurse-submodules=on-demand
fonctionnera réellement.
Voir commit 0301c82 , commit 1aa7365 (17 novembre 2016) par Brandon Williams ( mbrandonw
) .
(Fusionné par Junio C Hamano - gitster
- in commit 12cf113 , 16 déc 2016)
push run with --dry-run
n'effectue pas réellement (Git 2.11 déc.2016 et inférieur / avant) une exécution à sec lorsque push est configuré pour pousser des sous-modules à la demande.
Au lieu de cela, tous les sous-modules qui doivent être poussés sont en fait poussés vers leurs télécommandes tandis que toutes les mises à jour pour le superprojet sont effectuées en tant qu'exécution à vide.
Il s'agit d'un bogue et non du comportement prévu d'un run-run.Apprenez
push
à respecter l'--dry-run
option lorsqu'elle est configurée pour pousser récursivement des sous-modules «à la demande».
Cela se fait en passant le--dry-run
drapeau au processus enfant qui effectue une poussée pour un sous-module lors de l'exécution d'une analyse à sec.
Et toujours dans Git 2.12, vous avez maintenant une option " --recurse-submodules=only
" pour pousser les sous-modules sans pousser le superprojet de niveau supérieur .
Voir commit 225e8bf , commit 6c656c3 , commit 14c01bd (19 décembre 2016) par Brandon Williams ( mbrandonw
) .
(Fusionné par Junio C Hamano - gitster
- dans commit 792e22e , 31 janvier 2017)
git config push.recurseSubmodules on-demand
. Ensuite, un simplegit push
suffira pour tout pousser (repo principal et sous-modules). Voir ma réponse modifiée ci-dessous .