Comment se débarrasser de Git submodules statut non suivi?
Je n'arrive pas à me débarrasser du contenu inexistant dans les sous-modules de Git. git status donne:
# On branch master # Changes not staged for commit: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # (commit or discard the untracked or modified content in submodules) # # modified: bundle/snipmate (untracked content) # modified: bundle/surround (untracked content) # modified: bundle/trailing-whitespace (untracked content) # modified: bundle/zencoding (untracked content) # no changes added to commit (use "git add" and/or "git commit -a")
L'ajout du paramètre --ignore-submodules cache ces messages; mais je me demande s'il y a un moyen de se débarrasser de cette saleté d'une manière plus appropriée, plus proche du cœur.
8 réponses
depuis les rapports de situation git contenu non suivi, la véritable façon d'avoir un statut propre serait d'aller dans chacun de ces sous-modules et:
- ajouter et valider le contenu sans traces,
- ou faire référence au contenu non suivi dans un
.gitignorepropre à chaque module. - ou vous pouvez ajouter le même contenu ignoré au sous-module
.git/info/exclude, comme peci1 rapports dans les commentaires . -
ou d'ajouter sale à la sous-module de spécification, comme mentionné dans ezraspectre 's réponse (upvoted).
git config -f .gitmodules submodule.<path>.ignore untracked -
ou ajouter un global
.gitignorefichier (souvent~/.gitignore-global). Comme par exemple.DS_Storeou dans mon casCarthage/Buildcomme rapporté par Marián Černý dans les commentaires . Voir.gitginorel'homme page :
les modèles qu'un utilisateur veut que Git ignore dans toutes les situations (par exemple, les fichiers de sauvegarde ou temporaires générés par l'éditeur de son choix) vont généralement dans un fichier spécifié par
core.excludesFiledans le~/.gitconfigde l'utilisateur . Sa valeur par défaut est$XDG_CONFIG_HOME/git/ignore. Si$XDG_CONFIG_HOMEest non réglé ou vide,$HOME/.config/git/ignoreest utilisé à la place.
j'ai trouvé ce post de blog pour travailler dans l'ensemble. En ajoutant l'option ignore = dirty à chacune des entrées du fichier .gitmodules .
[submodule "zen-coding-gedit3"]
path = zen-coding-gedit3
url = git://github.com/leafac/zen-coding-gedit3.git
ignore = dirty
vous pouvez également aller à chaque dir submodule et agir comme un git séparé. Par exemple:
cd my/project/submodule
git status
... / obtient la liste des fichiers modifiés /
git add . //to add all of them to commit into submodule
git commit -m "message to your submodule repo"
vous pouvez également mettre à jour votre sous-module repo avec
git submodule update
après tout
ce serait dû au detached HEAD dans votre branche submodule. Allez dans votre chemin submodule (ex: ./bundle/snipmate ), puis git checkout master .
j'espère que cela aidera :)
j'ai coincé sur cette question hier, dans un projet qui avait près de 12 submodules.
git status affichait la sortie.
# On branch master
# Changes not staged for commit:
# (use "git add ..." to update what will be committed)
# (use "git checkout -- ..." to discard changes in working directory)
# (commit or discard the untracked or modified content in submodules)
#
# modified: proj1 (untracked content)
# modified: proj1 (modified content, untracked content)
# ...
pour résoudre l'erreur de contenu non suivi, j'ai dû supprimer les fichiers non suivis de tous les sous-modules (tous étaient des fichiers *.pyc , *.pyo générés par python) en utilisant un .gitignore .
pour résoudre l'autre, j'ai dû lancer git submodule update qui a mis à jour chacun des submodules.
dans ma situation, je clone des modules comme point de départ pour un nouveau module dans mon environnement ZF2. Ce que cela fait est de mettre les siens .dossier git dans le répertoire.
la Solution dans ce cas est de supprimer le .git dossier (vous aurez probablement besoin d'afficher les fichiers cachés pour l'afficher).
cela a très bien fonctionné pour moi:
git update-index --skip-worktree
si cela ne fonctionne pas avec le chemin d'accès, essayez le nom du fichier. Laissez-moi savoir si cela a fonctionné pour vous aussi.
Bye!
S'il s'agit d'un problème temporaire, vous pouvez entrer dans le dossier submodule et exécuter git reset HEAD --hard mais vous perdrez tous vos changements à l'intérieur du sous-module.