git stash gaffe: git stash pop et s'est retrouvé avec des conflits de fusion

J'ai fait un git stash popet je me suis retrouvé avec des conflits de fusion. J'ai supprimé les fichiers du système de fichiers et j'ai fait git checkoutcomme indiqué ci-dessous, mais il pense que les fichiers ne sont toujours pas fusionnés. J'ai ensuite essayé de remplacer les fichiers et de git checkoutrefaire le même résultat. J'ai essayé de le forcer avec le -fdrapeau. Toute aide serait appréciée!

chirag-patels-macbook-pro:haloror patelc75$ git status
app/views/layouts/_choose_patient.html.erb: needs merge
app/views/layouts/_links.html.erb: needs merge
# On branch prod-temp
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   db/schema.rb
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       unmerged:   app/views/layouts/_choose_patient.html.erb
#       unmerged:   app/views/layouts/_links.html.erb

chirag-patels-macbook-pro:haloror patelc75$ git checkout app/views/layouts/_choose_patient.html.erb
error: path 'app/views/layouts/_choose_patient.html.erb' is unmerged
chirag-patels-macbook-pro:haloror patelc75$ git checkout -f app/views/layouts/_choose_patient.html.erb
warning: path 'app/views/layouts/_choose_patient.html.erb' is unmerged

Voir man git merge ( COMMENT RÉSOUDRE LES CONFLITS ):

Après avoir vu un conflit, vous pouvez faire deux choses:

• Décidez de ne pas fusionner. Les seuls nettoyages dont vous avez besoin sont de réinitialiser le fichier d'index à la validation HEAD pour inverser 2. et de nettoyer les modifications de l'arborescence de travail effectuées par 2. et 3 .; git-reset --hard peut être utilisé pour cela.

• Résolvez les conflits. Git marquera les conflits dans l'arborescence de travail. Modifiez les fichiers en forme et ajoutez-les à l'index. Utilisez git commit pour sceller l'accord.

Et sous TRUE MERGE (pour voir à quoi se réfèrent 2. et 3.):

Lorsqu'il n'est pas évident de réconcilier les modifications, les événements suivants se produisent:

1. Le pointeur HEAD reste le même.

2. La référence MERGE_HEAD est définie pour pointer vers l'autre tête de branche.

3. Les chemins qui ont fusionné proprement sont mis à jour à la fois dans le fichier d'index et dans votre arborescence de travail.

4. ...

Donc: utilisez git reset --hardsi vous souhaitez supprimer les modifications de cachette de votre arborescence de travail, ou git resetsi vous voulez simplement nettoyer l'index et laisser les conflits dans votre arborescence de travail fusionner à la main.

Sous man git stash ( OPTIONS, pop ) vous pouvez lire en plus:

L'application de l'État peut échouer avec des conflits; dans ce cas, il n'est pas supprimé de la liste cachée. Vous devez résoudre les conflits à la main et appeler manuellement git stash drop par la suite.

Une chose similaire m'est arrivée. Je ne voulais pas mettre en scène les fichiers pour l'instant, alors je les ai ajoutés avec git add, puis je l'ai fait git reset. Cela a simplement ajouté puis supprimé mes modifications, mais a effacé les chemins non fusionnés.

Si, comme moi, ce que vous voulez habituellement, c'est remplacer le contenu du répertoire de travail par celui des fichiers cachés et que vous obtenez toujours un conflit, alors ce que vous voulez, c'est résoudre le conflit à l'aide git checkout --theirs -- .de la racine.

Après cela, vous pouvez git resetapporter toutes les modifications de l'index au répertoire de travail, car apparemment en cas de conflit, les modifications apportées aux fichiers non en conflit restent dans l'index.

Vous pouvez également vouloir exécuter git stash drop [<stash name>]après, pour vous débarrasser de la cachette, car git stash popne la supprimez pas en cas de conflits.

Notez que Git 2.5 (T2 2015) un futur Git pourrait essayer de rendre ce scénario impossible.

Voir commit ed178ef par Jeff King ( peff), 22 avril 2015.
^{(Fusionné par Junio ​​C Hamano - gitster- dans commit 05c3967 , 19 mai 2015)}

Remarque: cela a été annulé. Voir ci-dessous .

stash: nécessite un index propre pour appliquer / pop

Problème

Si vous avez organisé le contenu de votre index et exécuté " stash apply/pop", nous pouvons rencontrer un conflit et placer de nouvelles entrées dans l'index.
La restauration de votre état d'origine est difficile à ce stade, car des outils tels que "git reset --keep" effaceront tout ce qui est mis en scène .

En d'autres termes:

" git stash pop/apply" J'ai oublié de m'assurer que non seulement l'arbre de travail est propre, mais aussi que l'index est propre.
Ce dernier est important car une application cachée peut entrer en conflit et l'index sera utilisé pour la résolution des conflits.

Solution

Nous pouvons rendre cela plus sûr en refusant de postuler lorsqu'il y a des changements par étapes.

Cela signifie que s'il y avait des fusions avant en raison de l'application d'une stash sur des fichiers modifiés (ajoutés mais non validés), maintenant, il n'y aurait plus de fusion car la stash apply / pop s'arrêterait immédiatement avec:

Cannot apply stash: Your index contains uncommitted changes.

Vous forcer à valider les modifications signifie qu'en cas de fusion, vous pouvez facilement restaurer l'état initial (avant git stash apply/pop) avec a git reset --hard.

Voir commit 1937610 (15 juin 2015) et commit ed178ef (22 avril 2015) par Jeff King ( peff) .
^{(Fusionné par Junio ​​C Hamano - gitster- dans commit bfb539b , 24 juin 2015)}

Cette validation était une tentative d'améliorer la sécurité de l'application d'une stash, car le processus d'application peut créer des entrées d'index en conflit, après quoi il est difficile de restaurer l'état d'index d'origine.

Malheureusement, cela bloque certains workflows courants autour de " git stash -k", comme:

git add -p       ;# (1) stage set of proposed changes
git stash -k     ;# (2) get rid of everything else
make test        ;# (3) make sure proposal is reasonable
git stash apply  ;# (4) restore original working tree

Si vous "git commit" entre les étapes (3) et (4), alors cela fonctionne. Cependant, si ces étapes font partie d'un hook de pré-validation, vous n'avez pas cette possibilité (vous devez restaurer l'état d'origine, que les tests aient réussi ou échoué).