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.
D'accord. C'est un comportement assez standard du système de contrôle de révision. – Mort
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
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