Mise à jour : janvier 2021, dix ans plus tard :
" git diff
" ( homme ) a montré un arbre de travail de sous-module avec des éléments non tracés comme Submodule commit <objectname>-dirty
mais l'on s'attend naturellement à ce que le " -dirty
L'indicateur " s'alignerait sur " git describe --dirty
" ( homme ) qui ne considère pas la présence de fichiers non suivis dans l'arbre de travail comme une source de saleté.
L'incohérence a été corrigée avec Git 2.31 (Q1 2021).
Voir commit 8ef9312 (10 nov. 2020) par Sangeeta Jain ( sangu09
) .
(fusionné par Junio C Hamano -- gitster
-- sur commettre 0806279 , 25 janvier 2021)
diff
: ne pas montrer le sous-module avec des fichiers non suivis comme " -dirty
"
Signé par : Sangeeta Jain
Git diff rapporte un répertoire de sous-module en tant que -dirty
même lorsqu'il n'y a que des fichiers non suivis dans le répertoire du sous-module.
C'est incompatible avec ce que git describe --dirty
( homme ) dit lorsqu'il est exécuté dans le répertoire du sous-module dans cet état.
Faire --ignore-submodules=untracked
la valeur par défaut pour git diff
( homme ) lorsqu'il n'y a pas de variable de configuration ou d'option de ligne de commande, afin que la commande ne donne pas ' -dirty
à un sous-module dont l'arborescence de travail contient des fichiers non suivis, afin d'être cohérent avec la norme git describe --dirty
qui est exécuté dans l'arbre de travail du sous-module.
Et aussi faire --ignore-submodules=none
la valeur par défaut pour git status
( homme ) afin que l'utilisateur ne finisse pas par supprimer un sous-module qui a des fichiers non engagés (non suivis).
git config
inclut désormais dans son page de manuel :
Par défaut, cette valeur est fixée à untracked, de sorte que tous les sont ignorés.
Réponse originale (2011)
Comme mentionné dans l'article du blog de Mark Longair Les sous-modules Git expliqués ,
Les versions 1.7.0 et ultérieures de git contiennent une fonction changement ennuyeux dans le comportement du sous-module git.
Les sous-modules sont maintenant considérés comme sales s'ils ont des fichiers modifiés ou des fichiers non suivis. alors qu'auparavant ce n'était le cas que si HEAD dans le sous-module pointait vers le mauvais commit.
La signification du signe plus ( +
) dans la sortie de git submodule a changé, et la première fois que vous rencontrez cela, il faut un peu de temps pour comprendre ce qui ne va pas, par exemple en regardant les changelogs ou en utilisant git bisect sur git.git pour trouver le changement. Il aurait été beaucoup plus agréable pour les utilisateurs d'introduire un symbole différent pour "à la version spécifiée, mais sale".
Vous pouvez le réparer en :
- soit en validant ou en annulant les changements/évolutions dans chacun de vos sous-modules, avant de retourner au dépôt parent (où le diff ne devrait plus signaler les fichiers "sales"). Pour annuler toutes les modifications de votre sous-module, il suffit de
cd
dans le répertoire racine de votre sous-module et faire git checkout .
dotnetCarpenter commentaires que vous pouvez faire un : git submodule foreach --recursive git checkout .
- ou ajouter
--ignore-submodules
à votre git diff
pour ignorer temporairement ces sous-modules "sales".
Nouveau dans la version 1.7.2 de Git
Comme Noam commentaires ci-dessous , cette question mentionne que, depuis la version 1.7.2 de git, vous pouvez ignorer les submodules sales avec :
git status --ignore-submodules=dirty