git cherry-pick merge conflit tirant d'autres commits?
-
28-10-2019 - |
Question
Pour une raison quelconque, il semble que git cherry-pick tire d'autres commits lorsque les mouches ont des conflits de fusion. Ceux-ci disparaissent lorsque nous utilisons git mergetool
mais nous empêchent de modifier manuellement le fichier en conflit de fusion.
Quelqu'un sait-il pourquoi cela se produit?
Pour montrer ce que je veux dire, prenons un nouveau dépôt git 1.7.4 avec un seul fichier foo
:
header
footer
Créons à ce stade une nouvelle branche appelée bar
. De retour dans le master, ajoutons trois modifications à ce fichier dans des commits séparés.
Commit 1:
header
+add something
+
footer
Commit 2:
header
add something
+add something else
+
footer
Commit 3:
header
add something
add something else
+important change!
+
footer
Comme ce dernier commit est important, après coup, nous décidons de le retirer dans la branche bar
et git cherry-pick <commit>
sur cette branche.
Malheureusement, cela produit un conflit de fusion intéressant dans le fichier foo
:
header
<<<<<<< HEAD
=======
add something here
add something else here
important change!
>>>>>>> 356ca3c... important change
footer
Notez que git mergetool
semble faire la bonne chose et produit ceci:
header
+important change!
+
footer
Pourquoi le fichier en conflit de fusion contient-il des commits antérieurs à celui que nous avons essayé de sélectionner ?
La solution
Git est sceptique et ne fera pas de fusion s'il ne trouve pas les bords appropriés à ce à quoi le patch s'appliquerait.Le correctif s'appliquerait à un numéro de ligne qui n'existe pas.Inspectez le correctif pour ce commit et voyez qu'il est appliqué à un numéro de ligne qui n'a pas de sens.Puisqu'il s'agit d'un choix à la cerise, il ne prend pas en considération la façon dont le fichier est arrivé à être ainsi et qu'il serait correct d'ajouter cette entrée.J'espère que cela a du sens.