Impossible d’appliquer un cache au répertoire de travail

Je ne peux pas appliquer de cache au répertoire de travail.

Petite histoire:

D’abord, j’ai essayé de pousser certains changements, mais il disait: “non, vous ne pouvez pas, tirez d’abord” … alors je vais tirer les choses de github et ensuite pousser mes modifications. Quand j’ai essayé de tirer, j’ai dit que j’avais des changements qui allaient être écrasés et que je devais cacher mes changements. Ok, j’ai caché les changements … j’ai tiré et poussé les changements engagés. Mais maintenant, je ne peux pas restaurer les changements non sollicités sur lesquels je travaillais.

C’est l’erreur:

MyPath/File.cs already exists, no checkout Could not restore untracked files from stash 

Bien sûr, je ne comprends pas encore tous les concepts de git, ils me confondent un peu … peut-être que j’ai fait quelque chose de mal.

Ce serait génial si quelqu’un pouvait m’aider à résoudre ce problème … Je recherche Google depuis plus d’une heure maintenant, et je ne suis pas encore arrivé à une solution.

L’aide est très appréciée. Merci!

Il semble que votre réserve comprenait un fichier non suivi qui a ensuite été ajouté au repository. Lorsque vous essayez de le vérifier, Git refuse à juste titre car il écraserait un fichier existant.

Pour corriger, vous pouvez faire quelque chose comme supprimer ce fichier (ce n’est pas grave, il est toujours dans le repository), appliquer votre réserve, puis remplacer la version cachée du fichier par la version in-repo appropriée.

Edit: Il est également possible que le fichier n’ait été créé que dans l’arborescence de travail sans avoir été ajouté au repository. Dans ce cas, ne supprimez pas simplement le fichier local, mais plutôt:

  1. déplacez-le ailleurs
  2. appliquer la cachette
  3. fusionner manuellement les deux versions du fichier (arbre de travail ou déplacé).

Le moyen le plus sûr et le plus simple serait probablement de ranger les choses à nouveau:

 git stash -u # This will stash everything, including unstaged files git stash pop stash@{1} # This will apply your original stash 

Ensuite, si vous êtes satisfait du résultat, vous pouvez appeler

 git stash drop 

pour enlever votre cachette “sûre”.

Comme mentionné par @blahdiblah, vous pouvez supprimer manuellement les fichiers dont il se plaint, changer de twig, puis les append manuellement. Mais personnellement, je préfère restr “à l’intérieur”.

La meilleure façon de le faire est de convertir le cache en une twig. Une fois que c’est une twig, vous pouvez travailler normalement en utilisant les techniques / outils liés aux twigs que vous connaissez et aimez. Ceci est en fait une technique générale utile pour travailler avec des caches, même si vous ne possédez pas l’erreur répertoriée. Cela fonctionne bien car une cachette est vraiment un engagement sous les couvertures (voir PS).

Conversion d’une réserve en une twig

Ce qui suit crée une twig basée sur HEAD lorsque le cache a été créé, puis applique le cache (il ne le valide pas).

 git stash branch STASHBRANCH 

Travailler avec la “twig cachée”

Ce que vous faites ensuite dépend de la relation entre le cache et l’emplacement de votre twig cible (que j’appellerai ORIGINALBRANCH).

Option 1 – Rebase la twig stash normalement (beaucoup de modifications depuis stash)

Si vous avez apporté beaucoup de changements à votre ORIGINALBRANCH, vous devriez probablement traiter STASHBRANCH comme n’importe quelle twig locale. Validez vos modifications dans STASHBRANCH, rebassez-les sur ORIGINALBRANCH, puis passez à ORIGINALBRANCH et rebassez / fusionnez les modifications de STASHBRANCH. S’il y a des conflits, manipulez-les normalement (l’un des avantages de cette approche est que vous pouvez voir et résoudre les conflits).

Option 2 – Réinitialiser la twig d’origine pour qu’elle corresponde au cache (modifications limitées depuis la mémoire cache)

Si vous vous contentez de conserver des modifications mises en scène, puis que vous les avez validées, tout ce que vous voulez faire, c’est obtenir les modifications supplémentaires qui, lorsqu’elles ne sont pas mises en place, vous permettent de procéder comme suit. Il reviendra à votre twig et index d’origine sans changer votre copie de travail. Le résultat final sera vos modifications supplémentaires dans votre copie de travail.

 git symbolic-ref HEAD refs/heads/ORIGINALBRANCH git reset 

Contexte

Les caches commits aiment les twigs / tags (pas les patchs)

PS, il est tentant de penser à un cache comme un patch (tout comme il est tentant de penser à un commit comme un patch), mais un cache est en fait un commit contre le HEAD lors de sa création. Lorsque vous appliquez / pop, vous faites quelque chose de similaire à la sélection dans votre twig actuelle. Gardez à l’esprit que les twigs et les balises ne sont en fait que des références à des commits, de sorte que les stashes, les twigs et les balises ne sont, à bien des égards, que différentes manières de pointer un commit (et son historique).

Parfois nécessaire même si vous n’avez pas apporté de modifications au répertoire de travail

PPS, vous pouvez avoir besoin de cette technique après avoir simplement utilisé stash avec –patch et / ou –include-Untracked. Même sans modification des répertoires de travail, ces options peuvent parfois créer une réserve que vous ne pouvez pas simplement appliquer. Je dois avouer que je ne comprends pas bien pourquoi. Voir http://git.661346.n2.nabble.com/stash-refuses-to-pop-td7453780.html pour une discussion.

La solution: Vous devez supprimer le fichier en question, puis essayer de ranger des pop / appliquer à nouveau et cela devrait passer. Ne supprimez pas les autres fichiers, uniquement ceux mentionnés par l’erreur.

Le problème: Git craint parfois. Lors de l’exécution de git stash -u il inclut les fichiers non suivis (cool!) Mais il ne supprime pas ces fichiers non suivis et ne sait pas comment appliquer les fichiers non suivis cachés sur les rests (pas cool!), Ce qui rend le -u option assez inutile.

 git stash show --patch | patch -p1 

Mon opération pop bloquée de la même manière était due au fait que les fichiers restants ignoraient les fichiers (voir le fichier .gitignore). L’état de Git m’a montré suivi et non suivi, mais mes activités n’ont pas nettoyé les fichiers ignorés.

Détails: j’avais utilisé git stash save -a , extrait le master pour comstackr et voir le comportement d’origine, puis essayé de tout remettre en place pour continuer l’édition. Lorsque j’ai vérifié ma twig et que j’ai essayé de sortir, mes fichiers ignorés étaient toujours présents avant la sauvegarde. En effet, l’extraction de fichiers maîtres uniquement affectait les fichiers validés – elle n’a pas effacé les fichiers ignorés. Donc, la pop a échoué, disant essentiellement qu’elle ne voulait pas restaurer mes fichiers ignorés cachés au-dessus des fichiers encore présents. Il est regrettable que je ne puisse pas trouver un moyen de démarrer une session de fusion avec eux.

Finalement, j’ai utilisé git clean -f -d -x pour supprimer les fichiers ignorés. Fait intéressant, sur mes 30 ~, 4 fichiers restaient encore après le nettoyage (enfouis dans des sous-répertoires). Je devrai savoir dans quelle catégorie ils se trouvent, qu’ils doivent être supprimés manuellement.

Puis ma pop a réussi.

Cela m’est arrivé à maintes resockets, je range les fichiers non suivis avec git stash -u qui finissent par être ajoutés au repository et je ne peux plus appliquer les modifications cachées.

Je ne pouvais pas trouver un moyen de forcer git stash pop/apply pour remplacer les fichiers, donc je supprime d’abord les copies locales des fichiers non suivis qui étaient cachés ( soyez prudent car cela supprimera les modifications qui n’ont pas été commises ) et puis appliquez les modifications cachées:

 rm `git ls-tree -r stash@{0}^3 --name-only` git stash apply 

Enfin, j’utilise git status , git diff et d’autres outils pour vérifier et append des portions des fichiers supprimés s’il manque quelque chose.


Si vous souhaitez conserver des modifications non validées, vous pouvez d’abord créer une validation temporaire:

 git add --all git commit -m "dummy" rm `git ls-tree -r stash@{0}^3 --name-only` git stash apply 

Utilisez les outils qui vous conviennent pour fusionner les modifications précédemment validées dans les fichiers locaux et supprimez la validation factice:

 git reset HEAD~1 

Autre solution:

 cd to/root/your/project # Show what git will be remove git clean -n # If all is good git clean -f # If not all is good, see git clean --help # Finish git stash pop 

Avec Git 2.14.x / 2.15 (T3 2017), la solution de qwertzguy à partir de 2014 ne sera plus nécessaire.

Avant le troisième sortingmestre 2017, vous deviez supprimer le fichier en question, puis essayer de ranger des pop / appliquer à nouveau.
Avec la prochaine version de Git, vous n’aurez pas à le faire.

Voir commit bbffd87 (11 août 2017) par Nicolas Morey-Chaisemartin ( nmorey ) .
(Fusionné par Junio ​​C Hamano – gitster – dans commit 0ca2f32 , 23 août 2017)

stash : nettoyage des fichiers non suivis avant la réinitialisation

Si vous appelez git stash -u sur un référentiel contenant un fichier qui n’est plus ignoré suite à une modification en cours du fichier gitignore , ce fichier est caché mais pas supprimé de l’arborescence de travail.
Ceci est dû au fait que git-stash abord effectué un reset --hard qui efface la modification du fichier .gitignore et appelle ensuite git clean , laissant le fichier intact.
Cela provoque l’échec de git stash pop à cause du fichier existant .

Ce patch commute simplement l’ordre entre le nettoyage et la réinitialisation et ajoute un test pour cette firebase database.

Le moyen le plus sûr de suivre les cachettes

git stash -u

Cela cachera tout, y compris les changements non

git stash drop

une fois que vous avez fini de travailler dessus, enlevez votre cachette “sûre”.