258 votes

Git diff indique que le sous-projet est sale

Je viens de lancer un git diff, et j'obtiens le résultat suivant pour l'ensemble de mes quelque 10 sous-modules

diff --git a/.vim/bundle/bufexplorer b/.vim/bundle/bufexplorer
--- a/.vim/bundle/bufexplorer
+++ b/.vim/bundle/bufexplorer
@@ -1 +1 @@
-Subproject commit 8c75e65b647238febd0257658b150f717a136359
+Subproject commit 8c75e65b647238febd0257658b150f717a136359-dirty

Qu'est-ce que cela signifie ? Comment puis-je le réparer ?

295voto

VonC Points 414372

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

2 votes

Une autre bonne chose à savoir : vous pouvez toujours exécuter git commit -a sans avoir à se soucier d'ajouter ces changements. Bien qu'ils soient marqués par M à l'avant, ils ne finiront pas dans votre commission.

2 votes

Pour moi, je devais aller dans chaque sous-module sale et exécuter git clean -id .

1 votes

@GDP2 Ce que vous pouvez faire en une seule ligne, avec git submodule foreach --recursive git clean -id (à tester d'abord dans un repo de sauvegarde ;) )

27voto

Devpool Points 51

Pour ignorer tous les fichiers non suivis dans un sous-module, utilisez la commande suivante pour ignorer ces changements.

git config --global diff.ignoreSubmodules dirty

Il ajoutera l'option de configuration suivante à votre configuration git locale :

[diff]
  ignoreSubmodules = dirty

De plus amples informations sont disponibles ici

26voto

user1178907 Points 96

En supprimant également le sous-module, puis en exécutant git submodule init et git submodule update fera évidemment l'affaire, mais ce n'est pas toujours approprié ou possible.

2 votes

Cela a fonctionné pour moi lorsque j'ai converti certains dossiers existants en sous-modules et que j'ai ensuite transféré sur une autre machine qui avait encore les anciens dossiers.

19voto

Ralph Versteegen Points 567

EDIT : Cette réponse (et la plupart des autres) est obsolète ; voir La réponse de Devpool à la place .


À l'origine, il n'y avait pas d'options de configuration permettant de rendre " git diff --ignore-submodules " et " git status --ignore-submodules " le défaut global (mais voir aussi Définir les drapeaux par défaut de git sur les commandes ). Une alternative consiste à définir une valeur par défaut ignore sur chaque sous-module individuel que vous souhaitez ignorer (pour les deux types de modules). git diff et git status ), soit dans le .git/config (local seulement) ou .gitmodules (sera versionné par git). Par exemple :

[submodule "foobar"]
    url = git@bitbucket.org:foo/bar.git
    ignore = untracked

ignore = untracked pour ignorer uniquement les fichiers non suivis, ignore = dirty pour ignorer également les fichiers modifiés, et ignore = all pour ignorer également les commits. Il n'y a apparemment aucun moyen de le faire pour tous les sous-modules.

13voto

Robin Ren Points 11

C'est le cas parce que le pointeur que vous avez pour le submodule n'est pas ce qui se trouve réellement dans le répertoire du submodule. Pour résoudre ce problème, vous devez exécuter git submodule update encore :

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X