Git ne lancera / synchronisera / mettra à jour aucun nouveau sous-module

Avez-vous récemment mis à niveau vers la version 1.7.0.4 de git? Je l’ai fait et j’ai maintenant des problèmes similaires …

Edit: J’ai corrigé mon problème mais je n’ai absolument aucune idée du problème. J’ai supprimé manuellement les entrées de sous-modules des fichiers .git / config et .gitmodules et rajouté mes sous-modules avec les étapes ususal (add god submodule etc …) … Worksforme mais n’ajoute aucune valeur à ce thread.

J’ai eu le même problème – il s’est avéré que le fichier .gitmodules était validé, mais la validation réelle du sous-module (c’est-à-dire l’enregistrement de l’ID de validation du sous-module) ne l’était pas.

L’append manuellement semblait faire l’affaire – par exemple:

 git submodule add http://github.com/sciyoshi/pyfacebook.git external/pyfacebook 

(Même sans rien retirer de .git / config ou .gitmodules.)

Ensuite, engagez-le pour enregistrer l’ID correctement.

Ajout de quelques commentaires supplémentaires à cette réponse de travail: Si la mise à jour du sous-module init ou git du sous-module git ne fonctionne pas, alors, comme décrit ci-dessus, add url devrait faire l’affaire. On peut le vérifier par

  git config --list 

et on devrait obtenir une entrée du sous-module que vous voulez extraire du résultat de la commande git config –list. S’il y a une entrée de votre sous-module dans le résultat de la configuration, alors la mise à jour habituelle du sous-module git –init devrait tirer votre sous-module. Pour tester cette étape, vous pouvez renommer manuellement le sous-module, puis mettre à jour le sous-module.

  mv yourmodulename yourmodulename-temp git submodule update --init 

Pour savoir si vous avez des changements locaux dans le sous-module, vous pouvez le voir via git status -u (si vous voulez voir des changements dans le sous-module) ou git status –ignore-submodules (si vous ne voulez pas voir les changements dans le sous-module).

git version 2.7.4. Cette commande met à jour la git submodule update --init --force --remote code local git submodule update --init --force --remote

Eu le même problème, quand git ignoré les commandes init et update , et ne fait rien.

COMMENT RÉPARER

1. Votre dossier de sous-module doit être engagé dans git repo
2. Il ne devrait pas être dans .gitignore

Si ces conditions sont remplies, cela fonctionnera. Sinon, toutes les commandes s’exécuteront sans aucun message ni résultat.

Si vous avez fait tout ça, et que ça ne marche toujours pas:

1. Ajouter un sous-module manuellement, par exemple git submodule add git@... path/to
2. git submodule init
3. git submodule update
4. valider et pousser tous les fichiers – .gitmodules et votre dossier de module (notez que le contenu du dossier ne sera pas validé)
5. déposez votre repository git local
6. cloner un nouveau
7. assurez-vous que .git/config n’a pas encore de sous-module
8. Maintenant, git submodule init – et vous verrez un message enregistré par ce module
9. git submodule update – va chercher le module
10. Maintenant, regardez .git/config et vous trouverez le sous-module enregistré

Sorte de magie, mais aujourd’hui, j’ai lancé l’ git submodule init suivie de la git submodule sync suivie de la git submodule update et j’ai commencé à tirer mes sous-modules … Magic? Peut-être! C’est vraiment l’une des expériences les plus ennuyeuses avec Git…

Grattez ça. Je l’ai effectivement fait fonctionner en faisant git submodule update --init --recursive . J’espère que cela t’aides.

PS: Assurez-vous que vous êtes dans le répertoire racine de git, pas dans celui du sous-module.

Il semble y avoir beaucoup de confusion ici (aussi) dans les réponses.

git submodule init n’est pas destiné à générer par magie des choses dans .git / config (à partir de modules .git). Il est destiné à mettre en place quelque chose dans un sous-répertoire entièrement vide après avoir cloné le projet parent, ou en tirant un commit qui ajoute un sous-module précédemment inexistant.

En d’autres termes, vous suivez un git clone d’un projet qui a des sous-modules (que vous saurez par le fait que le clone a extrait un fichier .gitmodules) par un git submodule update --init --recursive .

Vous ne suivez pas git submodule add ... avec un git submodule init (ou git submodule update --init ), qui n’est pas censé fonctionner. En fait, l’ajout mettra déjà à jour le fichier .git / config approprié si les choses fonctionnent.

MODIFIER

Si un autre sous-module git qui n’existait pas auparavant a été ajouté par un autre utilisateur et que vous faites un git pull de ce commit, le répertoire de ce sous-module sera entièrement vide (lorsque vous exécuterez le git submodule status du sous-module git submodule status le nouveau hachage sera visible). avoir un - en face de lui. Dans ce cas, vous devez suivre votre git pull également avec une git submodule update --init (plus --recursive lorsqu’il s’agit d’un sous-module dans un sous-module) afin d’obtenir le nouveau -existant, sous-module vérifié; juste comme après un clone initial d’un projet avec des sous-modules (où évidemment vous n’aviez pas non plus ces sous-modules).

Selon la réponse de Dave James Miller, je peux confirmer que cela a fonctionné pour moi. L’important était de valider l’ID de validation des sous-projets. Le simple fait d’avoir l’entrée en .gitmodules ne suffisait pas.

Voici un engagement approprié:

https://github.com/dirkaholic/vagrant-php-dev-box/commit/d5f4c40bdbd80eefbb5ac6029823733f591435ae

J’ai eu le même problème.

.gitmodules avait le sous-module, mais après une commande git submodule init .git/config il n’était pas dans .git/config .

Éteint le développeur qui a ajouté le sous-module a également ajouté le répertoire de sous-module au fichier .gitignore . Cela ne fonctionne pas.

Comme vous, j’ai trouvé que la synchronisation des sous-modules git ne fait pas ce que vous attendez. Ce n’est qu’après avoir git submodule add un sous- git submodule add explicite qu’une url de sous-module est modifiée.

Donc, je mets ce script dans ~/bin/git-submodule-sync.rb :

https://gist.github.com/frimik/5125436

Et j’utilise également la même logique sur quelques scripts de déploiement git post-réception.

Tout ce que je dois faire maintenant est de modifier .gitmodules , puis d’exécuter ce script et cela fonctionne finalement comme je le pensais que git submodule sync était supposé.

Quand j’ai vu cela aujourd’hui, un développeur avait déplacé une partie de l’arborescence dans un nouveau sous-répertoire et il semblerait que son client git n’ait pas enregistré les règles de sous-projet mises à jour dans l’arborescence. aux emplacements périmés et aux sous-projets qui n’existaient plus dans l’arbre actuel.

L’ajout des sous-modules et la comparaison des commit du sous-module avec ceux trouvés dans git show $breaking_commit_sha (recherche des lignes correspondant à regexp ^-Subproject ) ^-Subproject d’ajuster au besoin les éléments fixes.

J’ai eu un problème similaire avec un sous-module. Il ne voulait tout simplement pas être cloné / tiré / mis à jour / peu importe.

Lorsque vous essayez de rappend le sous-module en utilisant le sous-module git submodule add [email protected] destination .

 A git directory for 'destination' is found locally with remote(s): origin [email protected] If you want to reuse this local git directory instead of cloning again from [email protected] use the '--force' option. If the local git directory is not the correct repo or you are unsure what this means choose another name with the '--name' option. 

J’ai donc essayé d’ appliquer la commande add :
git submodule add --force [email protected] destination

Ça a fonctionné dans mon cas.

J’ai eu le même problème aujourd’hui et j’ai compris que parce que j’ai tapé git submodule init j’avais ces lignes dans mon .git/config :

 [submodule] active = . 

Je l’ai enlevé et tapé:

 git submodule update --init --remote 

Et tout était revenu à la normale, mon sous-module mis à jour dans son sous-répertoire comme d’habitude.

La suppression du sous-module dir et de son contenu (dossier “external / pyfacebook”) s’il existe avant l’ git submodule add ... pourrait résoudre les problèmes.

Pour le compte rendu:
J’ai créé le même problème en ajoutant un référentiel vide en tant que sous-module. Dans ce cas, il n’y avait pas de hachage de référence disponible pour le sous-module, entraînant l’erreur décrite par l’affiche originale.

L’ajout forcé du repository après l’avoir engagé résout le problème (comme dans le post d’Arvids)
git submodule add --force [email protected] destination