Conflit avec git revert

Bonjour à tous,
J'ai voulu essayer de faire un revert sur un 2ème commit(2ème sur 3)
Code:

1 2 3 4 5 $ git log --oneline 9546de3 (HEAD -> master) 3ème info 42c88e2 2ème info 4b67b67 1ère info
mais j'ai ce message :
Code:

1 2 3 4 5 6 7 8 9 10 11 $ git revert --no-edit 42c88e2 Auto-merging revert.md CONFLICT (content): Merge conflict in revert.md error: could not revert 42c88e2... 2├¿me info hint: After resolving the conflicts, mark them with hint: "git add/rm <pathspec>", then run hint: "git revert --continue". hint: You can instead skip this commit with "git revert --skip". hint: To abort and get back to the state before "git revert", hint: run "git revert --abort".
Apparement on ne pourrait faire un revert que sur le dernier commit ? Ce qui peut sembler logique... Si quelqu'un a des infos MERCI

Bonjour,

Citation:

Apparement on ne pourrait faire un revert que sur le dernier commit ? Ce qui peut sembler logique... Si quelqu'un a des infos MERCI

Non, tu peux bel et bien appliquer ainsi le négatif de n'importe quel commit. Ce a quoi tu es confronté ici, en revanche, est un authentique conflit, qu'il va te falloir résoudre et qui aurait pu se produire de la même façon avec « merge ».

Le problème, ici, est que tu as modifié entretemps certaines des lignes qui avait déjà été affectées par le commit concerné. Donc, si Git applique le négatif pour les faire revenir à l'état initial, il va écraser les modifications introduites par les commits plus récents. En conséquence, Git va introduire dans le fichier concerné (dans le working directory, plus seulement dans l'index) des blocs qui vont contenir les deux versions aux positions concernées et cela va être à toi de choisir laquelle des deux il faut conserver, ou même de les remplacer par quelque chose de complètement différent au besoin. Ces blocs, au sein du fichier, apparaissent sous la forme :
<<<<<<< HEAD
Contenu de la ligne dernièrement modifiée
=======
Contenu de la ligne avant le commit à annuler
>>>>>>> parent of a62652c (m2)
C'est simplement du texte, donc tu peux effacer les marqueurs et le contenu obsolète comme tu as l'habitude de le faire en temps normal. Il faut simplement s'arranger pour que le bloc entier compris entre « <<< » et « >>> » inclus soit remplacé par du contenu valide.

La résolution des conflits est une des tâches majeures abordées par les CVS depuis le début de leur existence, tous produits confondus, et c'est en général source de sueurs (froides ou non) pour le développeur qui s'en sert. C'est pour cela qu'il est bon d'avoir un outil qui permette de manipuler facilement les branches et d'en résoudre le maximum en amont.

Voici deux exemples avec et sans conflit (que tu peux là encore reprendre dans un dépôt neuf et recrée pour l'occasion) :

Exemple sans conflit

Commit m1 : contenu du fichier « test1 » :
Code:

1 2 3 4 5 Un Deux Trois Quatre Cinq
Commit m2 : remplacement de la deuxième ligne.
Code:

1 2 3 4 5 Un Mardi Trois Quatre Cinq
Commit m3 : remplacement de la quatrième ligne
Code:

1 2 3 4 5 Un Mardi Trois Jeudi Cinq
Revert m2 : rétablissement de la deuxième ligne, la quatrième restant inchangée.
Code:

1 2 3 4 5 Un Deux Trois Jeudi Cinq
Exemple avec conflit

Commit m1 : contenu du fichier « test2 » :
Code:

1 2 3 4 5 Un Deux Trois Quatre Cinq
Commit m2 : modification de la deuxième ligne.
Code:

1 2 3 4 5 Un Mardi Trois Quatre Cinq
Commit m3 : nouvelle modification de la deuxième ligne.
Code:

1 2 3 4 5 Un **2** Trois Quatre Cinq
Revert m2 : conflit lors du rétablissement de la deuxième
Code:

1 2 3 4 5 6 7 8 9 Un <<<<<< **2** (Dernière modification en date) ====== Deux (État à rétablir en théorie et qui ne peut pas l'être directement parce que la ligne ne contient pas « Tuesday ») >>>>>> Trois Jeudi Cinq
Il est intéressant de remarquer qu'à chaque fois, Git se contente de comparer le commit à annuler et l'état courant du dépôt pour savoir si l'opération peut se faire directement, sans se soucier a priori de l'historique entre les deux (il le fera dans d'autres situations). Cela signifie qu'un revert s'effectuera sans conflit soit si les lignes concernées n'ont pas été modifiées dans l'intervalle, soit si elles l'ont été par certains commits mais ramenées ensuite à leur état initial par des commits postérieurs.

Merci et encore bravo pour tes explications.

J'ai testé tes deux exemples, pas de pb pour le premier, par contre j'ai remarqué que pour le second, si on le fait une fois il met bien à jour le fichier comme on le désire mais si on refait un autre revert ensuite(le même) il ne suit pas ton choix et liste toujours la dernière valeur du dernier commit soit içi **2**.
C'est je pense ce que tu m'a signalé :

Citation:

Cela signifie qu'un revert s'effectuera sans conflit soit si les lignes concernées n'ont pas été modifiées dans l'intervalle, soit si elles l'ont été par certains commits mais ramenées ensuite à leur état initial par des commits postérieurs.

L'effet est le même avec revert -- abort ou revert -- skip

Merci encore
A+