Comment suivre le contenu non suivi?

Voir ci-dessous la ligne continue pour ma question initiale.

J'ai un dossier dans mon répertoire local qui n'est pas suivi. Quand je cours git status, j'obtiens:

Changed but not updated:
modified:   vendor/plugins/open_flash_chart_2 (modified content, untracked content)

Lorsque je tape git add vendor/plugins/open_flash_chart_2puis réessaye git status, il est toujours dit non suivi. Que se passe-t-il?

Voici un simple résumé de ma dernière demi-heure:

• J'ai découvert que mon dépôt Github ne suivait pas mon vendor/plugins/open_flash_chart_2plugin. Plus précisément, il n'y a pas de contenu et une flèche verte apparaît sur l'icône du dossier.

• A essayé git submodule init

  No submodule mapping found in .gitmodules for path 'vendor/plugins/open_flash_chart_2'
  

• A essayé git submodule add git://github.com/korin/open_flash_chart_2_plugin.git vendor/plugins/open_flash_chart_2

  vendor/plugins/open_flash_chart_2 already exists in the index
  

• git status

  modified: vendor/plugins/open_flash_chart_2 (untracked content)
  

• J'ai recherché n'importe quel fichier nommé .gitmodulesdans mon référentiel / répertoire local mais je n'en ai pas trouvé.

Que dois-je faire pour que mes sous-modules fonctionnent afin que git puisse commencer le suivi correctement?

Cela peut être sans rapport (je l'inclus au cas où cela aiderait), mais chaque fois que je tape git commit -aplutôt que mon habituel git commit -m "my comments", cela génère une erreur:

E325: ATTENTION
Found a swap file by the name ".git\.COMMIT-EDITMSG.swp"
         dated: Thu Nov 11 19:45:05 2010
     file name: c:/san/project/.git/COMMIT_EDITMSG
      modified: YES
     user name: San   host name: San-PC
    process ID: 4268
While opening file ".git\COMMIT_EDITMSG"
         dated: Thu Nov 11 20:56:09 2010
  NEWER than swap file!  
Swap file ".git\.COMMIT_EDITMSG.swp" already exists!
[O]pen Read-Only, (E)dit anyway, (R)ecover, (D)elete it, (Q)uit, (A)bort:
Swap file ".git\.COMMIT_EDITMSG.swp" already exists!
[O]pen Read-Only, (E)dit anyway, (R)ecover, (D)elete it, (Q)uit, (A)bort:

Je suis un débutant complet chez Github et malgré mes efforts pour parcourir la documentation, je suis un peu perplexe face à ces problèmes particuliers. Je vous remercie.

Vous avez ajouté une vendor/plugins/open_flash_chart_2entrée «gitlink», mais ne l'avez jamais définie comme un sous-module. En fait, vous utilisez la fonctionnalité interne utilisée par git submodule (entrées gitlink) mais vous n'utilisez pas la fonctionnalité de sous-module elle-même.

Vous avez probablement fait quelque chose comme ceci:

git clone git://github.com/korin/open_flash_chart_2_plugin.git vendor/plugins/open_flash_chart_2
git add vendor/plugins/open_flash_chart_2

Cette dernière commande est le problème. Le répertoire vendor/plugins/open_flash_chart_2commence comme un référentiel Git indépendant. Habituellement, ces sous-référentiels sont ignorés, mais si vous dites à git add de l'ajouter explicitement, alors il créera une entrée gitlink qui pointe vers le commit HEAD du sous-référentiel au lieu d'ajouter le contenu du répertoire. Ce serait bien si git add refusait de créer de tels «semi-sous-modules».

Les répertoires normaux sont représentés comme des objets d'arborescence dans Git; Les objets tree donnent des noms et des autorisations aux objets qu'ils contiennent (généralement d'autres objets tree et blob — répertoires et fichiers, respectivement). Les sous-modules sont représentés comme des entrées «gitlink»; Les entrées gitlink contiennent uniquement le nom d'objet (hachage) du commit HEAD du sous-module. Le «référentiel source» pour un commit gitlink est spécifié dans le .gitmodulesfichier (et le .git/configfichier une fois que le sous-module a été initialisé).

Ce que vous avez est une entrée qui pointe vers un commit particulier, sans enregistrer le référentiel source pour ce commit. Vous pouvez résoudre ce problème en transformant votre gitlink dans un sous-module approprié, ou en supprimant le gitlink et en le remplaçant par du contenu «normal» (fichiers et répertoires simples).

Transformez-le en un sous-module approprié

Le seul élément qui vous manque pour définir correctement en vendor/plugins/open_flash_chart_2tant que sous-module est un .gitmodulesfichier. Normalement (si vous ne l'aviez pas déjà ajouté en tant qu'entrée gitlink nue), vous utiliseriez simplement git submodule add:

git submodule add git://github.com/korin/open_flash_chart_2_plugin.git vendor/plugins/open_flash_chart_2

Comme vous l'avez trouvé, cela ne fonctionnera pas si le chemin existe déjà dans l'index. La solution consiste à supprimer temporairement l'entrée gitlink de l'index, puis à ajouter le sous-module:

git rm --cached vendor/plugins/open_flash_chart_2
git submodule add git://github.com/korin/open_flash_chart_2_plugin.git vendor/plugins/open_flash_chart_2

Cela utilisera votre sous-référentiel existant (c'est-à-dire qu'il ne re-clonera pas le référentiel source) et mettra en scène un .gitmodulesfichier qui ressemble à ceci:

[submodule "vendor/plugins/open_flash_chart_2"]
    path = vendor/plugins/open_flash_chart_2
    url = git://github.com/korin/open_flash_chart_2_plugin.git vendor/plugins/open_flash_chart_2

Il fera également une entrée similaire dans votre référentiel principal .git/config(sans le pathparamètre).

Engagez-vous et vous aurez un sous-module approprié. Lorsque vous clonez le référentiel (ou poussez sur GitHub et clonez à partir de là), vous devriez être en mesure de réinitialiser le sous-module via git submodule update --init.

Remplacez-le par du contenu brut

L'étape suivante suppose que votre sous-référentiel dans vendor/plugins/open_flash_chart_2n'a pas d'historique local que vous souhaitez conserver (c'est-à-dire que tout ce dont vous vous souciez est l'arborescence de travail actuelle du sous-référentiel, pas l'historique).

Si vous avez un historique local dans le sous-référentiel qui vous intéresse, vous devez alors sauvegarder le répertoire du sous-référentiel .gitavant de le supprimer dans la deuxième commande ci-dessous. (Considérez également l' exemple de sous-arbre git ci-dessous qui préserve l'historique de HEAD du sous-référentiel).

git rm --cached vendor/plugins/open_flash_chart_2
rm -rf vendor/plugins/open_flash_chart_2/.git # BACK THIS UP FIRST unless you are sure you have no local changes in it
git add vendor/plugins/open_flash_chart_2

Cette fois, lors de l'ajout du répertoire, ce n'est pas un sous-référentiel, donc les fichiers seront ajoutés normalement. Malheureusement, depuis que nous avons supprimé le .gitrépertoire, il n'y a pas de moyen très simple de garder les choses à jour avec le référentiel source.

Vous pouvez envisager d'utiliser une fusion de sous - arborescence à la place. Cela vous permettra d'extraire facilement les modifications du référentiel source tout en gardant les fichiers «à plat» dans votre référentiel (pas de sous-modules). La commande tierce git subtree est un bon wrapper autour de la fonctionnalité de fusion de sous-arborescence.

git rm --cached vendor/plugins/open_flash_chart_2
git commit -m'converting to subtree; please stand by'
mv vendor/plugins/open_flash_chart_2 ../ofc2.local
git subtree add --prefix=vendor/plugins/open_flash_chart_2 ../ofc2.local HEAD
#rm -rf ../ofc2.local # if HEAD was the only tip with local history

Plus tard:

git remote add ofc2 git://github.com/korin/open_flash_chart_2_plugin.git
git subtree pull --prefix=vendor/plugins/open_flash_chart_2 ofc2 master

git subtree push --prefix=vendor/plugins/open_flash_chart_2 [email protected]:me/my_ofc2_fork.git changes_for_pull_request

git subtree a également une --squashoption qui vous permet d'éviter d'incorporer l'historique du référentiel source dans votre historique mais vous permet tout de même d'extraire les modifications en amont.

J'ai juste eu le même problème. La raison était qu'il y avait un sous-dossier contenant un dossier «.git». Le retirer a rendu git heureux.

1. J'ai supprimé les répertoires .git de ces nouveaux répertoires (cela peut créer un drame de sous-module. Google si cela vous intéresse.)
2. J'ai ensuite lancé git rm -rf --cached / les / new / répertoires
3. Ensuite, j'ai ré-ajouté les répertoires avec un git add. d'en haut

URL de référence https://danielmiessler.com/blog/git-modified-untracked/#gs.W0C7X6U

Pour souligner ce que j'ai dû extraire de la discussion de Chris Johansen avec OP (lié d'une réponse à une réponse):

git add vendor/plugins/open_flash_chart_2 # ajoutera gitlink, le contenu restera non suivi

git add vendor/plugins/open_flash_chart_2/ # NOTEZ LE SLASH !!!!

Le deuxième formulaire l'ajoutera sans gitlink, et le contenu est traçable. Le répertoire .git est commodément et automatiquement ignoré. Merci Chris!

J'utilise tout le temps l'astuce suggérée par Peter Lada, surnommée "faux sous-modules":

http://debuggable.com/posts/git-fake-submodules:4b563ee4-f3cc-4061-967e-0e48cbdd56cb

C'est très utile dans plusieurs scénarios (pe je l'utilise pour conserver toute ma configuration Emacs dans un référentiel, y compris le HEAD actuel de tous les référentiels git dans les répertoires de packages elpa / el-get, donc je pourrais facilement revenir en arrière / avancer vers un connu version de travail quand une mise à jour casse quelque chose).

http://progit.org/book/ch6-6.html

Je pense que vous devriez lire ceci pour en savoir un peu plus sur le sous-module. Il est bien écrit et il ne faut pas beaucoup de temps pour le lire.

J'ai eu le même problème avec un gros projet avec de nombreux sous-modules. Sur la base des réponses de Chris Johnsen ici et de VonC ici, je construis un court script bash qui itère à travers toutes les entrées gitlink existantes et les ajoute en tant que sous-modules appropriés.

#!/bin/bash

# Read all submodules in current git
MODULES=`git ls-files --stage | grep 160000`

# Iterate through every submodule path
while read -r MOD; do
  # extract submodule path (split line at whitespace and take string with index 3)
  ARRIN=(${MOD})
  MODPATH=${ARRIN[3]}

  # grep module url from .git file in submodule path
  MODURL=`grep "url = " $MODPATH/.git/config`
  MODURL=${MODURL##*=}

  # echo path and url for information
  echo $MODPATH
  echo $MODURL

  # remove existing entry in submodule index
  git rm --cached $MODPATH
  # add new entry in submodule index
  git submodule add $MODURL $MODPATH
done <<< "$MODULES"

Cela a résolu le problème pour moi, j'espère que cela vous sera utile.

Cela a très bien fonctionné pour moi:

git update-index --skip-worktree

Si cela ne fonctionne pas avec le chemin, essayez le nom de fichier. Faites-moi savoir si cela a fonctionné pour vous aussi.

Au revoir!

Eu le même problème, mais il n'a pas été résolu dans cette discussion.

J'ai également rencontré le problème du sous-module comme décrit dans l'ouverture du fil.

% git status          
# On branch master
# Changes not staged for commit:
#   modified:   bundle/taglist (untracked content)

En regardant le diff, j'ai reconnu un -dirty ajouté à un hachage: relire la documentation a résolu le problème pour moi. http://web.mit.edu/jhawk/mnt/spo/git/git-doc/user-manual.html Regardez la section "Pièges avec les sous-modules"

La raison était qu'il y avait des changements ou du contenu non suivi dans le sous-module. Je devais d'abord accéder au répertoire du sous-module, faire un "git add" + "git commit" pour que tout le contenu soit suivi dans le sous-module.

Then "git status" on the master stated
% git commit
# On branch master
# Changes not staged for commit:
#   modified:   bundle/taglist (new commits)

Maintenant, cette nouvelle HEAD du sous-module pourrait être validée dans le module maître.

J'ai récemment rencontré ce problème en travaillant sur un projet contractuel (réputé classifié). Le système dans lequel je devais exécuter le code n'avait pas d'accès Internet, pour des raisons de sécurité bien sûr, et donc l'installation de dépendances, en utilisant composer et npm, devenait une énorme douleur.

Après de longues délibérations avec mon collègue, nous avons décidé de simplement l'ailer et de copier-coller nos dépendances plutôt que de faire installer composer ou installer npm.

Cela nous a conduit à NE PAS ajouter de fournisseurs et npm_modules dans gitignore. C'est à ce moment que j'ai rencontré ce problème.

Changed but not updated:
modified:   vendor/plugins/open_flash_chart_2 (modified content, untracked content)

J'ai un peu cherché sur Google et trouvé ce fil de discussion utile sur SO. N'étant pas trop pro dans Git, et étant un peu enivré en travaillant dessus, j'ai juste cherché tous les sous-modules dans le dossier des fournisseurs

find . -name ".git"

Cela m'a donné quelques 4-5 dépendances qui avaient git sur eux. J'ai supprimé tous ces dossiers .git et voila, cela a fonctionné. Je sais que c'est un hack, et pas très geek de toute façon. Ô dieux de SO, pardonnez-moi! La prochaine fois, je promets de lire sur gitlinks et d'obéir à O puissant Linus Tovalds.

Cette question a déjà reçu une réponse, mais j'ai pensé ajouter au mélange ce que j'ai découvert lorsque j'ai reçu ces messages.

J'ai un dépôt appelé playgroundqui contient un certain nombre d'applications sandbox. J'ai ajouté deux nouvelles applications à partir d'un tutoriel au playgroundrépertoire en clonant le repo du tutoriel. Le résultat était que les trucs git des nouvelles applications pointaient vers le dépôt du tutoriel et non vers mon dépôt. La solution était de supprimer le .gitrépertoire de chacun des répertoires de ces applications, les répertoires mvdes applications en dehors du playgroundrépertoire, puis de mvles remettre en marche git add .. Après cela, cela a fonctionné.

J'ai résolu ce problème en supprimant le fichier .git de mon sous-dossier.

1. Supprimez d'abord le fichier .git de votre sous-dossier
2. Ensuite, supprimez votre sous-dossier de git en exécutant ce code, git rm -rf --cached your_subfolder_name
3. Ensuite, ajoutez à nouveau votre dossier par git add. commander

Allez d'abord dans le répertoire : vendor / plugins / open_flash_chart_2 et DELETE

PUIS :

git rm --cached vendor/plugins/open_flash_chart_2  
git add .  
git commit -m "Message"  
git push -u origin master  

git status  

PRODUCTION

Sur le maître de succursale
Votre succursale est à jour avec «origine / maître».
rien à valider, le répertoire de travail est nettoyé