Ignorer les nouveaux commits pour le sous-module git

Contexte

Utiliser Git 1.8.1.1 sous Linux. Le référentiel se présente comme suit:

master book 

Le sous-module a été créé comme suit:

 $ cd /path/to/master $ git submodule add https://user@bitbucket.org/user/repo.git book 

Le sous-module book est propre:

 $ cd /path/to/master/book/ $ git status # On branch master nothing to commit, working directory clean 

Problème

Le maître, par contre, montre qu’il y a des “nouveaux commits” pour le sous-module livre:

 $ cd /path/to/master/ $ git status # On branch master # Changes not staged for commit: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: book (new commits) # no changes added to commit (use "git add" and/or "git commit -a") 

Git devrait ignorer complètement le répertoire du sous-module, de sorte que le maître soit également propre:

 $ cd /path/to/master/ $ git status # On branch master nothing to commit, working directory clean 

Échec de la tentative # 1 – sale

Dans le fichier master/.gitmodules est le suivant, comme dans cette réponse :

 [submodule "book"] path = book url = https://user@bitbucket.org/user/repo.git ignore = dirty 

Échec de la tentative n ° 2 – non suivi

Changé master/.gitmodules à la suivante, selon cette réponse :

 [submodule "book"] path = book url = https://user@bitbucket.org/user/repo.git ignore = untracked 

Échec de la tentative # 3 – showUntrackedFiles

Edité master/.git/config à la suivante, selon cette réponse :

 [status] showUntrackedFiles = no 

Échec de la tentative n ° 4 – ignorer

Ajout du répertoire book au fichier maître ignore:

 $ cd /path/to/master/ $ echo book > .gitignore 

Échec de la tentative # 5 – cloner

Ajout du répertoire du livre au maître comme suit:

 $ cd /path/to/master/ $ rm -rf book $ git clone https://user@bitbucket.org/user/repo.git book 

Question

Comment le sous-module book peut-il se trouver dans son propre répertoire de référentiel sous le référentiel master mais avoir ignoré le sous-module book ? C’est-à-dire que les éléments suivants ne doivent pas s’afficher:

 # # modified: book (new commits) # 

Comment supprimer ce message lors de l’exécution de git status dans le référentiel maître?

Un article sur les pièges du sous-module git suggère qu’il s’agit d’une utilisation inappropriée des sous-modules?

    Pour inclure un autre référentiel qui n’a pas besoin d’être suivi dans son super repo, essayez ceci:

     $ cd /path/to/master/ $ rm -rf book $ git clone https://user@bitbucket.org/user/repo.git book $ git add book $ echo "book" >> .gitignore 

    Alors engagez.

    Comme indiqué dans l’article lié sur les pièges des sous-modules git :

    … le seul lien entre le parent et le sous-module est [la] valeur enregistrée du SHA extrait du sous-module qui est stocké dans les commits du parent.

    Cela signifie qu’un sous-module n’est pas enregistré par sa twig ou son tag extrait, mais toujours par un commit spécifique; que commit (SHA) est enregistré dans le super repo (celui contenant le sous-module) comme un fichier texte normal (marqué comme telle, bien sûr).

    Lorsque vous extrayez un commit différent dans le sous-module ou effectuez un nouveau commit, le super-repo verra que son SHA extrait a été modifié. C’est à ce moment que vous obtenez la ligne modified (new commits) du git status .

    Pour éliminer cela, vous pouvez soit:

    • git submodule update , qui réinitialisera le sous-module à la validation actuellement enregistrée dans le super repo (pour plus de détails, voir la page de manuel du git submodule ; ou
    • git add book && git commit à enregistrer le nouveau SHA dans le super repo.

    Comme mentionné dans les commentaires, envisagez d’abandonner le sous-module book : clonez-le dans le super repo, si le suivi de son état dans le cadre du super repo n’est pas nécessaire.

    Il suffit de courir:

     $ git submodule update 

    Cela rétablira l’ancien sous-module (spécifié dans repo parent), sans mettre à jour le référentiel parent avec la dernière version du sous-module.

    Il existe deux types d’avis de modification que vous pouvez supprimer (à partir de git 1.7.2).

    Le premier est le contenu non suivi qui se produit lorsque vous apportez des modifications à votre sous-module, mais que vous ne les avez pas encore validées. Le référentiel parent les remarque et l’état de git le signale en conséquence:

     modified: book (untracked content) 

    Vous pouvez les supprimer avec:

     [submodule "book"] path = modules/media url = https://user@bitbucket.org/user/repo.git ignore = dirty 

    Cependant, une fois que vous aurez validé ces modifications, le référentiel parent le remarquera à nouveau et les signalera en conséquence:

     modified: book (new commits) 

    Si vous souhaitez les supprimer également, vous devez ignorer toutes les modifications.

     [submodule "book"] path = book url = https://user@bitbucket.org/user/repo.git ignore = all 

    Git 2.13 (Q2 2017) appenda une autre manière d’inclure un sous-module qui n’a pas besoin d’être suivi par son repository parent.

    Dans le cas de l’OP:

     git config submodule..active false 

    Voir commit 1b614c0 , commettre 1f8d711 , commettre bb62e0a , valider 3e7eaed , valider a086f92 (17 mars 2017) et valider ee92ab9 , commettre 25b31f1 , valider e7849a9 , valider 6dc9f01 , valider 5c2 Dhabi (16 mars 2017) par Brandon Williams ( mbrandonw ) .
    (Fusionné par Junio ​​C Hamano – gitster – dans commit a93dcb0 , 30 mars 2017)

    submodulesubmodule : decouple url et intérêt du sous-module

    Actuellement, l’option de configuration submodule..url du submodule..urlsubmodule..url est utilisée pour déterminer si un sous-module donné présente un intérêt pour l’utilisateur. Cela finit par être encombrant dans un monde où l’on veut que différents sous-modules soient extraits dans différents worktrees ou un mécanisme plus généralisé pour sélectionner les sous-modules qui présentent un intérêt.

    Dans le futur, avec le support de worktree pour les sous-modules, il y aura plusieurs arbres de travail, chacun d’entre eux ne nécessitant qu’un sous-ensemble des sous-modules extraits.
    L’URL (c’est-à-dire où le référentiel de sous-module peut être obtenu) ne doit pas différer entre les différents arbres de travail.

    Il peut également être commode pour les utilisateurs de spécifier plus facilement des groupes de sous-modules qui les intéressent plutôt que d’exécuter « git submodule init » sur chaque sous-module qu’ils souhaitent extraire dans leur arbre de travail.

    À cette fin, deux options de configuration sont submodule..active : submodule..active . submodule..active .

    • La configuration submodule.active contient une pathspec qui spécifie les sous-modules qui doivent exister dans l’arborescence de travail.
      • Le submodule..active config est un indicateur booléen utilisé pour indiquer si ce sous-module doit exister dans l’arborescence de travail.

    Il est important de noter que submodule.active fonctionne différemment des autres options de configuration car il utilise une pathspec.
    Cela permet aux utilisateurs d’adopter au moins deux nouveaux workflows:

    1. Les sous-modules peuvent être regroupés avec un répertoire principal, de sorte qu’un chemin d’access, par exemple « lib/ », couvre tous les modules library-ish pour permettre à ceux qui sont intéressés par les modules library-ish de définir « submodule.active = lib/ » any et tous les modules dans ‘ lib/ ‘ sont intéressants.
    2. Une fois la fonction pathspec-atsortingbute créée, les utilisateurs peuvent étiqueter les sous-modules avec des atsortingbuts pour les regrouper, de manière à utiliser un pathspec large avec les atsortingbuts requirejs, par exemple ‘ :(attr:lib) ‘ Les atsortingbuts de lib ‘sont intéressants.
      Étant donné que le fichier .gitatsortingbutes , tout comme le fichier .gitmodules , est suivi par le superprojet, lorsqu’un sous-module se déplace dans l’arborescence du superprojet, le projet peut définir le chemin d’access à l’atsortingbut .gitatsortingbutes . sous-module en .gitmodules .

    La réponse de Nevik Rehnel est certainement la bonne pour ce que vous demandez: je ne voulais pas avoir de sous-module, comment diable puis-je me sortir de cette situation?! .

    Seulement, si votre projet principal nécessite le sous-module book , il est intéressant de le garder tel quel, car les autres utilisateurs qui contrôlent votre projet peuvent alors ne pas avoir de commande spéciale git à exécuter (eh bien … commandes pour utiliser des sous-modules, mais il est encore plus simple de gérer, globalement, je pense.)

    Dans votre cas, vous apportez des modifications au référentiel du book et, à un moment donné, vous validez ces modifications. Cela signifie que vous avez de nouveaux commits dans ce sous-module, qui ont une nouvelle référence SHA1.

    Ce que vous devez faire dans le répertoire principal est de valider ces modifications dans le référentiel maître.

     cd /path/to/master git commit . -m "Update 'book' in master" 

    Cela mettra à jour la référence SHA1 dans master à la version la plus récente disponible dans le référentiel de book . En conséquence, cette validation permet aux autres utilisateurs de récupérer tous les référentiels master et de book à la pointe.

    Donc, en fait, vous vous retrouvez avec un engagement de plus lorsque vous apportez des modifications à un sous-module. Il est semi-transparent si vous apportez également des modifications à certains fichiers du référentiel master , puisque vous les validez simultanément.

    Courir

     git submodule update 

    au niveau de la racine.