Ignorer les nouveaux commits pour le sous-module git

Question

Contexte

Utilisation de 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, en revanche, montre qu'il y a de "nouveaux commits" pour le sous-module livre:

$ cd /path/to/master/ $ git status # On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." 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, afin 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 n ° 1 - sale

À l'intérieur du fichier master/.gitmodules est le suivant, selon ceci réponse :

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

Échec de la tentative n ° 2 - non suivi

Modifié master/.gitmodules à ce qui suit, comme ceci réponse :

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

Échec de la tentative n ° 3 - showUntrackedFiles

Modifié master/.git/config à ce qui suit, comme ceci réponse :

[status] showUntrackedFiles = no

Échec de la tentative n ° 4 - ignorer

Ajout du répertoire du livre au fichier principal ignoré:

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

Échec de la tentative # 5 - clone

Ajout du répertoire de livres 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 git ignore le sous-module book? Autrement dit, 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 pièges du sous-module git suggère-t-il une utilisation inappropriée du sous-module?

Nevik Rehnel · Accepted Answer

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

Engagez-vous ensuite.

Comme indiqué dans l'article lié git submodule pièges :

... le seul lien entre le parent et le sous-module est [la] valeur enregistrée de l'extraction du sous-module SHA qui est stockée dans les validations du parent.

Cela signifie qu'un sous-module n'est pas enregistré par sa branche ou sa balise extraite, mais toujours par un commit spécifique; ce commit (SHA) est enregistré dans le super-repo (celui contenant le sous-module) comme un fichier texte normal (il est marqué comme une telle référence, bien sûr).

Lorsque vous extrayez un commit différent dans le sous-module ou faites un nouveau commit dedans, le super-repo verra que son check out SHA a changé. C'est alors que vous obtenez la ligne modified (new commits) de git status.

Pour éliminer cela, vous pouvez soit:

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

Shiv Kumar · Answer

Exécutez simplement:

$ git submodule update

Cela ramènera le sous-module à l'ancien commit (spécifié dans parent-repo), sans mettre à jour le parent-repo avec la dernière version du sous-module.

greuze · Answer

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 git status 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 avez validé ces modifications, le référentiel parent en tiendra de nouveau compte et les signalera en conséquence:

modified: book (new commits)

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

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

VonC · Answer

Git 2.13 (Q2 2017) ajoutera une autre façon d'inclure un sous-module qui n'a pas besoin d'être suivi par son référentiel parent.

Dans le cas du PO:

git config submodule.<name>.active false

Voir commit 1b614c , commit 1f8d711 , commit bb62e0a , commit 3e7eaed , commit a086f92 (17 mars 2017), et commit ee92ab9 , commit 25b31f1 , commit e7849a9 , commit 6dc9f01 , commit 5c2bd8b (16 mars 2017) par Brandon Williams (mbrandonw) .
^{(Fusionné par Junio C Hamano - gitster - in commit a93dcb , 30 mars 2017)}

submodule: découpler l'URL et l'intérêt du sous-module

Actuellement, l'option de configuration submodule.<name>.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 lourd dans un monde où nous voulons faire vérifier différents sous-modules dans différents postes de travail ou un mécanisme plus généralisé pour sélectionner les sous-modules qui sont intéressants.

Dans un futur avec la prise en charge de worktree pour les sous-modules, il y aura plusieurs arborescences de travail, dont chacune n'aura peut-être besoin que d'un sous-ensemble des sous-modules extraits.
L'URL (qui est l'endroit où le référentiel de sous-module peut être obtenu) ne doit pas différer entre les différentes arborescences de travail.

Il peut également être pratique pour les utilisateurs de spécifier plus facilement les groupes de sous-modules qui les intéressent plutôt que d'exécuter "git submodule init <path>" Sur chaque sous-module qu'ils souhaitent extraire dans leur arborescence de travail.

À cette fin, deux options de configuration sont introduites, submodule.active Et submodule.<name>.active.

La configuration submodule.active Contient une spécification de chemin qui spécifie quels sous-modules doivent exister dans l'arborescence de travail.

La configuration submodule.<name>.active Est un indicateur booléen utilisé pour indiquer si ce sous-module particulier 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 prend une pathspec.
Cela permet aux utilisateurs d'adopter au moins deux nouveaux workflows:

Les sous-modules peuvent être regroupés avec un répertoire principal, de sorte qu'une spécification de chemin, par ex. 'lib/' Couvrirait tous les modules de bibliothèque-ish pour permettre à ceux qui sont intéressés par les modules de bibliothèque-ish de définir "submodule.active = lib/" Une seule fois pour dire n'importe lequel et tous les modules de 'lib/' sont intéressants.

Une fois que la fonction d'attribut pathspec est inventée, les utilisateurs peuvent étiqueter des sous-modules avec des attributs pour les regrouper, de sorte qu'une large pathspec avec des exigences d'attribut, par exemple ':(attr:lib)', peut être utilisé pour dire que tous les modules avec l'attribut 'lib' sont intéressants.
Étant donné que le fichier .gitattributes, 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 ajuster le chemin qui obtient l'attribut dans .gitattributes, tout comme il peut ajuster le chemin d'accès du sous-module dans .gitmodules.

Alexis Wilke · Answer

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 sortir de cette situation?!.

Seulement, si votre projet master nécessite le sous-module book, c'est un geste sympa de le conserver tel quel, car de cette façon, les autres utilisateurs qui achèteront votre projet pourront alors profiter de ne pas avoir de _ git commande à exécuter (enfin ... il y a des commandes spéciales pour utiliser les sous-modules, mais c'est encore plus simple à gérer, dans l'ensemble, je pense.)

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

Ce que vous devez faire dans le répertoire maître 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 vers la dernière version disponible dans le référentiel book. Par conséquent, cette validation permet aux autres de récupérer tous les référentiels master & book à la pointe.

Donc, en fait, vous vous retrouvez avec un commit de plus chaque fois que vous apportez des modifications à un sous-module. Il est semi-transparent si vous apportez également des modifications à certains fichiers dans le référentiel master car vous vous engagez les deux en même temps.