Ignorez-vous un sous-module git dans votre .gitignore ou l'intégrez-vous à votre dépôt ?

Question

J'ai ajouté un sous-module à mon projet en project_dir/vendor/submodule_one Maintenant, à chaque fois que j'exécute git status J'obtiens modified: vendor/submodule_one (new commits) .

Ma question est la suivante : quelle est la meilleure façon de traiter ce problème ? Dois-je ajouter le vendor/submodule_one -dans mon dossier .gitignore car mon projet principal ne devrait pas avoir besoin de connaître les spécificités de mon sous-module ?

Ou bien, lorsque je modifie mon sous-module et que j'y apporte des modifications, dois-je également apporter des modifications à mon projet principal ?

Je commence à utiliser les submodules et je n'ai pas trouvé beaucoup d'informations au-delà de leur mise en place.

Answer 1

Non, vous n'avez pas besoin d'ajouter votre sous-module à votre .gitignore : ce que le parent verra de votre sous-module est un gitlink (a entrée spéciale, mode 160000 ).

Cela signifie que toute modification effectuée directement dans un sous-module doit être suivie d'une validation dans le répertoire parent.
De cette façon, le répertoire parent enregistrera le bon commit pour l'état du sous-module : Ce commit est le "gitlink" mentionné ci-dessus ;

Pour en savoir plus sur cette politique, consultez la rubrique " git submodule update (vraie nature des submodules) ".
L'idée principale des sous-modules est une approche par composants où vous faites référence à d'autres dépôts à des commits spécifiques. Mais si vous changez quoi que ce soit dans ces sous-modules, vous devez également mettre à jour ces références dans le dépôt parent.

---

Notez qu'avec Git 2.13 (Q2 2017), alors que l'option no en ignorant le lien git, vous pouvez toujours ignorer le sous-module avec :

git config submodule.<name>.active false

Voir plus sur " Ignorer les nouveaux commits pour le sous-module git ".

---

Note : avec Git 2.15.x/2.16 (Q1 2018), ignorer un sous-module est plus précis.
" git status --ignored --untracked "ne s'est pas arrêté à l'arbre de travail d'un projet séparé qui est intégré dans un répertoire ignoré et a listé les fichiers de cet autre projet, au lieu d'afficher le répertoire lui-même comme étant ignoré.

Véase commit fadb482 (25 Oct 2017) par Johannes Schindelin ( dscho ) .
(fusionné par Junio C Hamano -- gitster -- en commit da7996a , 06 Nov 2017)

status Les sous-modules dans les répertoires exclus : ne pas s'embrouiller avec les sous-modules dans les répertoires exclus

Nous passons méticuleusement les exclude à l'indicateur treat_directory() afin d'indiquer que les fichiers qu'elle contient sont exclus plutôt que non suivis lors de la récursivité.

Mais nous n'avons pas encore traité les sous-modules de la même manière.

Pour cette raison, git status --ignored --untracked w submodule dans un gitignored tracked/ montrerait le sous-menu " Untracked files section ", par exemple

On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)

    tracked/submodule/

Ignored files:
  (use "git add -f <file>..." to include in what will be committed)

    tracked/submodule/initial.t

Au lieu de cela, nous voudrions qu'il affiche le sous-module dans l'espace " Ignored files " section :

On branch master
Ignored files:
  (use "git add -f <file>..." to include in what will be committed)

    tracked/submodule/

Answer 2

Pour une raison ou une autre sous-module.nom-de-module.actif n'a pas fonctionné pour moi.

C'est pourquoi j'ai utilisé sous-module.nom-de-module.ignore

git config submodule.<your module path>.ignore all

https://git-scm.com/docs/gitmodules - Vous trouverez ici une description des valeurs possibles pour le paramètre

Cela fonctionne pour moi pour les messages (nouveaux commits) et (contenu modifié).

Answer 3

Pour compléter la réponse acceptée, j'ai constaté que l'ajout du dossier du sous-module Git à .gitignore pose des problèmes, en particulier lorsque l'on essaie de créer un nouveau clone du projet. En particulier, l'exécution des commandes normales de clonage de submodule a eu pour résultat que le dossier de submodule était vide :

git submodule init
git submodule update
git pull --recurse-submodules

Ce n'est qu'en essayant de réexécuter

git submodule add <Git repo> <submodule folder>

le problème était clair, d'après les résultats :

The following path is ignored by one of your .gitignore files:
<submodule folder>
Use -f if you really want to add it.

Au lieu d'ajouter -f J'ai donc supprimé le dossier Git submodule de .gitignore et j'ai relancé les commandes de clonage de submodule - qui ont maintenant créé le dossier avec succès. Je pense qu'il y a peut-être un bug dans le fait que l'une des commandes de clonage de sous-modules respecte .gitignore mais ne prévient pas qu'elle saute un sous-module en conséquence.