Ignorer les nouveaux commits pour le submodule git

Question

Contexte

Utilisation de Git 1.8.1.1 sous Linux. Le dépôt 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

En book Le sous-module est propre :

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

Problème

Le master, quant à lui, montre qu'il y a de "nouveaux commits" pour le sous-module book :

$ 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 master soit également propre :

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

Échec de la première tentative - sale

Dans le dossier master/.gitmodules est le suivant, selon ce qui suit réponse :

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

Échec de la tentative #2 - non tracé

Modifié master/.gitmodules à ce qui suit, conformément à ce qui suit 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, conformément à ce qui suit réponse :

[status]
   showUntrackedFiles = no

Échec de la tentative n° 4 - ignorer

Ajout du répertoire des livres au fichier maître des ignorés :

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

Tentative ratée #5 - clone

Ajout du répertoire book au master comme suit :

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

Question

Comment le book soit dans son propre répertoire de dépôt sous le nom de master mais que git ignore le book sous-module ? C'est-à-dire que ce qui suit ne devrait pas s'afficher :

#
#       modified:   book (new commits)
#

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

Un article sur Les pièges du sous-module git suggère une utilisation inappropriée du sous-module ?

Answer 1

Cours juste :

$ git submodule update

Ceci rétablira le submodule à l'ancien commit (spécifié dans le parent-repo), sans mettre à jour le parent-repo avec la dernière version du submodule.

Answer 2

Pour inclure un autre dépôt, 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-vous.

Comme indiqué dans le lien Article sur les pièges des submodules 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 submodule n'est pas sauvegardé par sa branche ou son tag check-out, mais toujours par un commit spécifique ; ce commit (SHA) est sauvegardé dans le super-repo (celui qui contient le submodule) comme un fichier texte normal (il est marqué comme une telle référence, bien sûr).

Lorsque vous vérifiez un autre commit dans le sous-module ou faire un nouveau commit dans celui-ci, le super-repo verra que sa SHA extraite a changé. C'est alors que vous obtenez le modified (new commits) ligne de git status .

Pour éliminer cela, vous pouvez soit :

• git submodule update qui réinitialisera le sous-module au commit actuellement sauvegardé dans le super-repo (pour plus de détails voir le site git submodule page d'accueil ; ou
• git add book && git commit pour enregistrer le nouveau SHA dans le super-repo.

Comme mentionné dans les commentaires, envisagez d'abandonner la book submodule : clonez-le à l'intérieur du super-repo, si le suivi de son état en tant que partie du super-repo n'est pas nécessaire.

Answer 3

Il existe deux types d'avis de modification que vous pouvez supprimer (depuis 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 dépôt parent les remarque et git status les 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, dès que vous livrez ces changements, le référentiel parent en prend note et les signale en conséquence :

modified:   book (new commits)

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

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

Answer 4

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 repo parent.

Dans le cas de l'OP :

git config submodule.<name>.active false

Voir commettre 1b614c0 , commettre 1f8d711 , commettre bb62e0a , commettre 3e7eaed , commettre a086f92 (17 mars 2017), et commettre ee92ab9 , commettre 25b31f1 , commettre e7849a9 , commettre 6dc9f01 , commettre 5c2bd8b (16 mars 2017) par Brandon Williams ( mbrandonw ) .
(fusionné par Junio C Hamano -- gitster -- en commettre a93dcb0 , 30 mars 2017)

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

Actuellement, le submodule.<name>.url L'option de configuration est utilisée pour déterminer si un sous-module donné est intéressant pour l'utilisateur. Cela se traduit par encombrant dans un monde où l'on veut que différents submodules soient vérifiés dans des arbres de travail différents ou un mécanisme plus généralisé pour sélectionner les sous-modules qui présentent un intérêt.

I arbres de travail, chacun d'entre eux pouvant n'avoir besoin que d'un sous-ensemble des submodules vérifiés.
L'URL (qui est l'endroit où le dépôt du sous-module peut être obtenu) ne doit pas différer entre les différents arbres de travail.

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

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

• En submodule.active config contient une spécification de chemin d'accès qui indique quels sous-modules doivent être
  • En submodule.<name>.active config est un drapeau booléen ce sous-module particulier doit exister dans l'arbre de travail.

Il est important de noter que submodule.active fonctionne différemment de les autres options de configuration puisqu'elle prend un chemin d'accès.
Cela permet aux utilisateurs d'adopter au moins deux nouveaux flux de travail :

1. Les sous-modules peuvent être groupés avec un répertoire principal, de telle sorte qu'un chemin d'accès, par exemple ' lib/ couvrirait tous les modules de bibliothèque afin de permettre à ceux qui s'intéressent à ces derniers de définir " submodule.active = lib/ " juste une fois pour dire que tous les modules dans ' lib/ sont intéressants.
2. Une fois que la fonctionnalité pathpec-attribute est inventée, les utilisateurs peuvent étiqueter les sous-modules avec des attributs pour les regrouper, de sorte qu'un pathpec large avec des exigences d'attributs, par exemple ' :(attr:lib) ', peut être utilisé pour dire n'importe quel et tous les modules avec le ' lib Les attributs sont intéressants.
   Depuis le .gitattributes tout comme le fichier .gitmodules est suivi par le superprojet, lorsqu'un sous-module se déplace dans l'arbre du superprojet, le projet peut ajuster quel chemin reçoit l'attribut dans le fichier .gitattributes tout comme il peut ajuster quel chemin a le sous-module en .gitmodules .

Answer 5

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

Seulement, si votre master Le projet nécessite le book c'est un beau geste de le garder comme tel, car de cette façon, les autres utilisateurs qui vérifient votre projet peuvent profiter du fait qu'il n'y a pas d'exigence particulière en matière d'accessibilité. git commande à exécuter (enfin... il y a quelques commandes spéciales pour utiliser les submodules, mais cela reste plus simple à gérer, globalement, je pense).

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

Ce que vous devez faire dans le répertoire principal est de commettre ces changements dans le référentiel principal.

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 book dépôt. Par conséquent, ce commit permet à d'autres personnes de vérifier tous les fichiers de la master & book les dépôts à l'extrémité.

Donc, en fait, vous vous retrouvez avec un commit de plus chaque fois que vous apportez des modifications à un sous-module. C'est semi-transparent si vous apportez également des modifications à certains fichiers dans le fichier master puisque vous commettez les deux en même temps.