2017-09-20 3 views
0

Ainsi,Git Stash Pop - Résoudre les conflits avec mergetool

Je suis venu à travers ce tout à coup, comme, sous forme épique gaffeur, rendu mon application inutile, mais pop git stash (ou appliquer) gère automatiquement la fusion conflits. Quand il le fait, il ajoute les deux versions au fichier comme ceci:

<<<<<<< Updated [remote] 
    Change from Remote 
======= 
    Change from Stash 
>>>>>>> Stashed changes 

sachant pas cela d'abord me coûter un certain temps, comme les lignes ajoutées invalidés le fichier xml. Donc, je me demande s'il y a un moyen de forcer git stash à ne pas fusionner automatiquement mais de laisser les conflits en place pour qu'ils puissent être résolus avec le git mergetool, au lieu de m'obliger à ouvrir chaque fichier dans le éditeur et gérer le processus "merte" sans le bénéfice de l'outil conçu pour les conflits de fusion.

Merci Jaeden « Sifo Dyas » al'Raec Ruiner

Répondre

1

Le processus de fusion utilisé par git stash apply -Ce est la première moitié de git stash pop -est le même que toute autre fusion, en termes d'effet laissé derrière:

$ git status 
On branch master 
nothing to commit, working tree clean 
$ git log --all --decorate --oneline --graph 
* f9a96c0 (HEAD -> master) conflicting changes for stash 
| * 069a595 (refs/stash) WIP on master: 6fee57d add file "file" 
| |\ 
|// 
| * c466c42 index on master: 6fee57d add file "file" 
|/ 
* 6fee57d add file "file" 
* 2353af8 initial 

à ce stade, que je lance git stash apply ou git stash pop, je reçois un conflit de fusion et le processus s'arrête (ne fait pas la seconde moitié de git stash pop):

$ git stash apply 
Auto-merging file 
CONFLICT (content): Merge conflict in file 
$ git reset --hard HEAD 
HEAD is now at f9a96c0 conflicting changes for stash 
$ git stash pop 
Auto-merging file 
CONFLICT (content): Merge conflict in file 
$ git stash list 
[email protected]{0}: WIP on master: 6fee57d add file "file" 

Quelle est l'indice est maintenant l'état unmerged, avec trois copies de fichier file présents:

$ git ls-files --stage 
100644 239c0dc4252320079890fff28cd408eb825776f5 0 README 
100644 2983120c0897fea017d8398b5ffdc5e3ef0e17ad 1 file 
100644 27b6da381575999c9ba975e9df9ba6caa45e3165 2 file 
100644 080f90d42698e258e3efa8059c78ebfd5fdd7bd8 3 file 

et git mergetool est assez heureux de courir à ce moment:

$ git mergetool 
[snip configuration complaint - I never use git mergetool 
so it is not configured] 
Merging: 
file 

Normal merge conflict for 'file': 
    {local}: modified file 
    {remote}: modified file 
Hit return to start merge resolution tool (bc): 

Donc, je me demande s'il y a un moyen d'imposer git stash de ne pas fusionner automatiquement mais de laisser les conflits en place ...

Les trois versions du fichier sont présentes dans l'index à ce stade. Seulement deux d'entre eux, --ours (généralement la même version que la version de validation HEAD) et --theirs (la version stashed-commit, dans ce cas), ont la syntaxe de commande git checkout pratique, mais vous pouvez également extraire la version de base de fusion, en utilisant la syntaxe :<number>:path . L'exécution de git mergetool le fait pour vous: extrait les versions de base, de gauche/locale/ours et de droite/à distance/theirs, juste avant l'exécution de l'outil de fusion configuré. Par conséquent, je ne suis pas vraiment sûr de savoir quelle était votre question.

+0

D'accord. C'est un comportement assez standard du système de contrôle de révision. – Mort

+0

Eh bien, quand je lance git merge, disons de la branche Revision_5 et développe une branche, et supposons qu'il y ait un conflit. il va tenter de fusionner automatiquement. Si ça peut être génial, mais si ce n'est pas le cas, il n'ajoute pas ces tags gênants et les nôtres dans le fichier, il les laisse tout simplement et la branche active dans la ligne de commande devient (develop | MERGING). Êtes-vous en train de dire que même si cela ne se produit pas avec git stash, et qu'il fusionne simplement les deux versions dans le fichier unique, git mergetool fonctionnera toujours et me permettra de réparer la fusion? – JaedenRuiner

+0

Dans tous les cas de conflit de fusion *, * Git est censé laisser le fichier de l'arbre de travail marqué comme ceci. Les originaux sont tous stockés dans l'index, de sorte qu'au lieu des trois versions actives habituelles d'un fichier (HEAD, index stage 0, work-tree), vous finissez avec * cinq * versions actives (HEAD; index stades 1, 2, 3, arbre de travail). Exécuter 'git add' ou' git rm' sur l'un des chemins réduit les trois copies d'index d'ordre supérieur à la copie d'index à un seul étage-0, en prenant la version de l'arbre de travail. Le script 'git mergetool' exécute le' git add' pour vous s'il pense que l'outil qu'il a exécuté a réussi. – torek