(Git 2.22, Q2 2019, a introduit git submodule set-branch --branch aBranch -- <submodule_path>
)
Notez que si vous avez un sous-module existant qui ne suit pas encore une branche , alors ( si vous avez git 1.8.2+ ):
Assurez-vous que le dépôt parent sait que son sous-module suit désormais une branche:
cd /path/to/your/parent/repo
git config -f .gitmodules submodule.<path>.branch <branch>
Assurez-vous que votre sous-module est bien au plus tard de cette branche:
cd path/to/your/submodule
git checkout -b branch --track origin/branch
# if the master branch already exist:
git branch -u origin/master master
(«origine» étant le nom du référentiel distant en amont à partir duquel le sous-module a été cloné.
Un git remote -v
intérieur de ce sous-module l'affichera. Généralement, il s'agit de «origine»)
N'oubliez pas d'enregistrer le nouvel état de votre sous-module dans votre référentiel parent:
cd /path/to/your/parent/repo
git add path/to/your/submodule
git commit -m "Make submodule tracking a branch"
La mise à jour ultérieure de ce sous-module devra utiliser l' --remote
option:
# update your submodule
# --remote will also fetch and ensure that
# the latest commit from the branch is used
git submodule update --remote
# to avoid fetching use
git submodule update --remote --no-fetch
Notez qu'avec Git 2.10+ (Q3 2016), vous pouvez utiliser ' .
' comme nom de branche:
Le nom de la branche est enregistré comme submodule.<name>.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 nom que la branche actuelle dans le référentiel actuel .
Mais, comme commenté par LubosD
Avec git checkout
, si le nom de la branche à suivre est " .
", cela tuera votre travail non engagé!
Utilisez git switch
plutôt.
Cela signifie Git 2.23 (août 2019) ou plus.
Voir " Confus pargit checkout
"
Si vous souhaitez mettre à jour tous vos sous-modules en suivant une branche:
git submodule update --recursive --remote
Notez que le résultat, pour chaque sous-module mis à jour, sera presque toujours une tête détachée , comme le note Dan Cameron dans sa réponse .
( Clintm note dans les commentaires que, si vous exécutez git submodule update --remote
et que le sha1 résultant est le même que la branche sur laquelle le sous-module est actuellement, il ne fera rien et laissera le sous-module toujours "sur cette branche" et non dans un état de tête détachée. )
Pour s'assurer que la branche est réellement extraite (et cela ne modifiera pas le SHA1 de l' entrée spéciale représentant le sous-module pour le référentiel parent), il suggère:
git submodule foreach -q --recursive 'branch="$(git config -f $toplevel/.gitmodules submodule.$name.branch)"; git switch $branch'
Chaque sous-module référencera toujours le même SHA1, mais si vous effectuez de nouveaux commits, vous pourrez les pousser car ils seront référencés par la branche que vous souhaitez que le sous-module suive.
Après cette poussée dans un sous-module, n'oubliez pas de revenir au référentiel parent, d'ajouter, de valider et de pousser le nouveau SHA1 pour ces sous-modules modifiés.
Notez l'utilisation de $toplevel
, recommandée dans les commentaires d' Alexander Pogrebnyak .
$toplevel
a été introduit dans git1.7.2 en mai 2010: commit f030c96 .
il contient le chemin absolu du répertoire de niveau supérieur (où .gitmodules
est).
dtmland
ajoute dans les commentaires :
Le script foreach ne parviendra pas à extraire les sous-modules qui ne suivent pas une branche.
Cependant, cette commande vous donne les deux:
git submodule foreach -q --recursive 'branch="$(git config -f $toplevel/.gitmodules submodule.$name.branch)"; [ "$branch" = "" ] && git checkout master || git switch $branch' –
La même commande mais plus facile à lire:
git submodule foreach -q --recursive \
'branch="$(git config -f $toplevel/.gitmodules submodule.$name.branch)"; \
[ "$branch" = "" ] && \
git checkout master || git switch $branch' –
umläute affine la commande de dtmland avec une version simplifiée dans les commentaires :
git submodule foreach -q --recursive 'git switch $(git config -f $toplevel/.gitmodules submodule.$name.branch || echo master)'
plusieurs lignes:
git submodule foreach -q --recursive \
'git switch \
$(git config -f $toplevel/.gitmodules submodule.$name.branch || echo master)'
Avant Git 2.26 (T1 2020), une extraction à laquelle il est demandé de récupérer récursivement les mises à jour dans les sous-modules produit inévitablement des rames de sortie, et il devient difficile de repérer les messages d'erreur.
La commande a appris à énumérer les sous-modules qui avaient des erreurs à la fin de l'opération .
Voir commit 0222540 (16 janvier 2020) par Emily Shaffer ( nasamuffin
) .
(Fusionné par Junio C Hamano - gitster
- en commit b5c71cc , 05 fév 2020)
fetch
: accentuer l'échec lors de la récupération du sous-module
Signé par: Emily Shaffer
Dans les cas où une extraction de sous-module échoue alors qu'il y a plusieurs sous-modules, l'erreur de la seule extraction de sous-module échouée est enterrée sous l'activité sur les autres sous-modules si plus d'une extraction est retombée fetch-by-oid
.
Signalez un échec tardivement afin que l'utilisateur sache que quelque chose s'est mal passé et où .
Parce que fetch_finish()
est uniquement appelé de manière synchrone par run_processes_parallel,
mutexage n'est pas nécessaire autour submodules_with_errors
.