Comment résoudre un conflit de stash git sans commit ?

Question

Comme demandé dans cette question Je veux aussi savoir comment résoudre un conflit d'intérêts. git stash pop sans ajouter toutes les modifications à un commit (tout comme le fait "git stash pop" sans conflit).

Mon approche actuelle n'est pas très cool parce que je le fais de cette façon :

git stash pop  # -> CONFLICT
git stash drop
# [resolve conflict]
# [add conflict files]
git reset HEAD # <all files that are in commit-mode>

---

Comment se reproduire :

mkdir foo; cd foo; git init
echo "1" > one
echo "2" > two
git add -A; git commit -m "first"
echo "1.1" > one
echo "2.1" > two
git stash
echo "2.2" > two
git commit -a -m "second"
echo "Only this file would stay in HEAD without the conflict" > third
git add third
git stash pop
git status

2016-06-27 : Ajout d'un nouveau fichier appelé 'third' à l'exemple pour montrer que les solutions de contournement comme celle de scy ne fonctionnent que pour les HEADs vides mais ne règlent pas le problème initial qui est que le HEAD n'a pas le même contenu comme pour un HEAD. git stash pop sans conflit.

Answer 1

Supposons que vous ayez un scénario dans lequel vous cachez vos modifications afin de les tirer depuis l'origine. Peut-être parce que vos modifications locales sont juste debug: true dans un fichier de paramètres. Maintenant, vous tirez et quelqu'un a introduit un nouveau paramètre à cet endroit, créant un conflit.

git status dit :

# On branch master
# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#   both modified:      src/js/globals.tpl.js
no changes added to commit (use "git add" and/or "git commit -a")

Ok. J'ai décidé de faire ce que Git a suggéré : j'ai résolu le conflit et je me suis engagé :

vim src/js/globals.tpl.js
# type type type …
git commit -a -m WIP   # (short for "work in progress")

Maintenant ma copie de travail est dans l'état que je veux, mais j'ai créé un commit que je ne veux pas avoir. Comment puis-je me débarrasser de ce commit sans modifier ma copie de travail ? Attendez, il y a une commande populaire pour cela !

git reset HEAD^

Ma copie de travail n'a pas été modifiée, mais le commit WIP a disparu. C'est exactement ce que je voulais ! (Notez que je n'utilise pas --soft ici, parce que s'il y a des fichiers fusionnés automatiquement dans votre cachette, ils sont mis à jour automatiquement et donc vous vous retrouveriez avec ces fichiers à nouveau mis à jour après reset .)

Mais il reste encore une chose : La page de manuel de git stash pop nous rappelle que " L'application de l'état peut échouer en cas de conflits ; dans ce cas, il n'est pas supprimé de la liste de la réserve. Vous devez résoudre les conflits à la main et appeler git stash drop manuellement après." C'est donc exactement ce que nous faisons maintenant :

git stash drop

Et c'est fait.

Answer 2

Au lieu d'ajouter les modifications que vous effectuez pour résoudre le conflit, vous pouvez utiliser la fonction git reset HEAD file pour résoudre le conflit sans mettre en scène vos changements.

Il se peut toutefois que vous deviez exécuter cette commande deux fois. Une fois pour marquer le conflit comme résolu et une fois pour annuler les changements qui ont été mis en scène par la routine de résolution de conflit.

Il est possible qu'il y ait un mode de réinitialisation qui fasse ces deux choses simultanément, bien qu'il n'y en ait pas actuellement.

Answer 3

git checkout stash -- .

a fonctionné pour moi.

Note cette méthode peut être dangereuse car elle n'essaie pas de fusionner les modifications de la cachette dans votre copie de travail. écrase avec les fichiers cachés à la place. Donc vous pouvez perdre vos modifications non validées.

Answer 4

Il semble que ce soit la réponse que vous cherchez. Je ne l'ai pas encore essayé personnellement, mais il semble que cela puisse faire l'affaire. Avec cette commande, GIT essaiera d'appliquer les changements tels qu'ils étaient auparavant, sans essayer de les ajouter tous pour le commit.

git stash apply --index

voici l'explication complète :

http://git-scm.com/book/en/Git-Tools-Stashing

Answer 5

git stash branch qui crée une nouvelle branche pour vous, vérifie le commit sur lequel vous étiez lorsque vous avez caché votre travail. le commit sur lequel vous étiez quand vous avez caché votre travail, réapplique votre travail à cet endroit, et puis laisse tomber la cachette si l'application est réussie. check ce