Pourquoi git revert se plaint-il d’une option -m manquante?

Donc, je travaille sur un projet avec d’autres personnes, et il y a plusieurs fourchettes de github sur lesquelles on travaille. Quelqu’un vient de faire un correctif pour un problème et j’ai fusionné avec sa fourchette, mais j’ai alors réalisé que je pouvais trouver une meilleure solution. Je veux revenir sur l’engagement que je viens de faire. J’ai essayé de faire ça avec git revert HEAD mais ça m’a donné cette erreur:

  fatal: Commit  est une fusion mais aucune option -m n'a été donnée. 

Qu’est-ce que ça veut dire? Lorsque j’ai fusionné et engagé, j’ai utilisé l’option -m pour dire “Fusionné avec “.

Que fais-je mal ici?

Par défaut, git revert refuse de renvoyer une validation de fusion car ce que cela signifie en réalité est ambigu. Je présume que votre HEAD est en fait un engagement de fusion.

Si vous voulez annuler la validation de la fusion, vous devez spécifier le parent de la fusion que vous souhaitez considérer comme la ligne principale, c’est-à-dire ce que vous voulez rétablir.

Ce sera souvent le parent numéro un, par exemple si vous étiez sur master et que git merge unwanted , puis a décidé de revenir à la fusion de unwanted . Le premier parent serait votre twig master pré-fusion et le deuxième parent serait la partie unwanted .

Dans ce cas, vous pouvez faire:

 git revert -m 1 HEAD 

Disons que l’autre gars a créé la barre au-dessus de foo, mais vous avez créé baz en attendant, puis fusionné, donnant une histoire de

  $ git lola
 * 2582152 (HEAD, master) Fusionner la twig 'otherguy'
 | \  
 |  * c7256de (otherguy) bar
 * |  b7e7176 baz
 | /  
 * 9968f79 foo 

Remarque: git lola est un alias non standard mais utile.

Aucun dé avec git revert :

  $ git reviens HEAD
 fatal: Commit 2582152 ... est une fusion mais aucune option -m n'a été donnée. 

Charles Bailey a donné une excellente réponse comme d’habitude. Utiliser git revert comme dans

  $ git reviens --no-edit -m 1 HEAD
 [master e900aad] Revert "Fusionner la twig 'otherguy'"
  0 fichiers modifiés, 0 insertions (+), 0 suppressions (-)
  supprimer le mode 100644 bar 

supprime efficacement la bar et produit un historique de

  $ git lola
 * e900aad (HEAD, master) Revenir "Fusionner la twig 'otherguy'"
 * 2582152 Fusionner une twig 'otherguy'
 | \  
 |  * c7256de (otherguy) bar
 * |  b7e7176 baz
 | /  
 * 9968f79 foo 

Mais je soupçonne que vous voulez jeter le commit de fusion:

  $ git reset --hard HEAD ^
 HEAD est maintenant à b7e7176 baz

 $ git lola
 * b7e7176 (HEAD, master) baz
 |  * c7256de (otherguy) bar
 | /  
 * 9968f79 foo 

Comme indiqué dans le manuel de git rev-parse

^ , par exemple HEAD ^, v1.5.1^0
Un suffixe ^ à un paramètre de révision signifie le premier parent de cet object de validation. ^ signifie le n- ième parent ( ie ^ équivaut à ^1 ). En tant que règle spéciale, ^0 signifie le commit lui-même et est utilisé lorsque est le nom d’object d’un object tag qui fait référence à un object commit.

donc avant d’invoquer git reset , HEAD^ (ou HEAD^1 ) était b7e7176 et HEAD^2 était c7256de, c’est -à- dire respectivement le premier et le deuxième parent du commit de fusion.

Attention à git reset --hard car cela peut détruire le travail.

J’ai eu ce problème, la solution était de regarder le graphe de validation (en utilisant gitk) et de voir que j’avais les éléments suivants:

 * commit I want to cherry-pick (x) |\ | * branch I want to cherry-pick to (y) * | |/ * common parent (x) 

Je comprends maintenant que je veux faire

 git cherry-pick -m 2 mycommitsha 

C’est parce que -m 1 fusionnerait en fonction du parent commun où -m 2 fusionne en fonction de la twig y, c’est celui auquel je veux choisir.