web-dev-qa-db-fra.com

Git Rebase ne continuera pas après un conflit de suppression/modification

Je suis au milieu d'une rebase de mon maître à une branche de scène

git checkout stage
git rebase master

À un moment donné, j'ai supprimé deux fichiers, puis modifié les deux fichiers en fonction de GIT.

warning: too many files, skipping inexact rename detection
CONFLICT (delete/modify): test-recommendation-result.php deleted in HEAD and modified in [Bug] Fix test recommender. Version [Bug] Fix test recommender of test-recommendation-result.php left in tree.
CONFLICT (delete/modify): test-recommendation.php deleted in HEAD and modified in [Bug] Fix test recommender. Version [Bug] Fix test recommender of test-recommendation.php left in tree.
Failed to merge in the changes.
Patch failed at 0015.

Je veux dire "Ouais git, vas-y et supprime ces fichiers" alors ...

git rm test-recommendation-result.php
git rm test-recommendation.php
git rebase --continue

Git dit:

Applying [Bug] Fix test recommender
No changes - did you forget to use 'git add', Stupid?

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".

Je dis "Ne m'appelle pas" Stupide "et fais ce que je t'ai dit de faire!"

Nous sommes maintenant dans une impasse. Qui a raison et comment puis-je résoudre ce problème?

45
Clutch

do git add -A suivi de git rebase --continue. Cela devrait ajouter toutes les modifications, y compris la suppression des fichiers, puis continuer.

Il n'y a aucune garantie que le commit n'ait pas d'autres fichiers qui ne sont pas en conflit et devrait être fusionné. git rebase --skip perdrait ces fichiers. Tu ne veux pas ça.

J'espère que cela t'aides.

44
Adam Dymitruk

Quand tout le reste échoue, lisez le message.

Ce correctif tente de modifier deux fichiers, mais ils ont déjà été supprimés. les supprimer à nouveau n'a rien fait.

Il suffit de lancer git rebase --skip.

2
Josh Lee

Je frappe ceci quand un commit a ajouté un fichier binaire en conflit avec un fichier existant.

Je me suis débrouillé par:

  • supprimer le fichier existant,
  • modifier un seul caractère en un commentaire dans un fichier différent, et 
  • "git ajouter" ce changement non pertinent. 

Git était à nouveau heureux. :)

1
Guy Lancaster

Il n'y a pas une séquence magique de commandes à toujours exécuter pour résoudre cette situation. S'il y en avait, les développeurs de GIT se contenteraient d'effectuer cette action et de ne pas déranger l'utilisateur.

Considérez que cette erreur peut également se produire si vous choisissez, transplantez ou restaurez les modifications qui affectent un fichier qui a été restructuré ou renommé.

Par exemple, supposons que vous ayez une branche appelée support/1.0 qui ressemble à ceci:


 com.somewhere.package-a /
 MyClass.Java 
 MyOtherClass.Java 

Supposons maintenant qu'entre les versions 1.0 et 1.5, cela soit refactoré. Alors maintenant, release/1.5 ressemble à ceci:


 com.somewhere.package /
 une/
 MyClass.Java 
 ANewClass.Java 
 b /
 MyOtherClass.Java 

Supposons maintenant que vous avez une branche de fonctionnalité de la version 1.5 que vous essayez de transférer en arrière vers une branche de fonctionnalité basée sur support/1.0. Dans cette validation, les trois fichiers de la version 1.5 ont été modifiés (MyClass.Java, ANewClass.Java et MyOtherClass.Java).

Si vous essayez d’utiliser Rebase ou Cherry Pick pour vous aider avec l’arrière-port, l’une des deux choses suivantes peut se produire:

  • Si les fichiers ont été renommés dans le cadre des modifications en cours de transplantation, .__ ou parmi les modifications immédiates apportées au fichier par le parent immédiat. avec les noms originaux, et simplement appliquer les modifications aux fichiers originaux.

  • Si les fichiers ont été renommés suffisamment loin dans l'historique de Version 1.5 (après la publication de la version 1.0), GIT vous indiquera que les fichiers Ont été supprimés dans release/1.0 car elle ne le sait pas. 1.0 correspondent aux changements de 1.5.

ANewClass.Java déclenchera presque certainement l'erreur de suppression, à moins qu'il ne soit ajouté dans l'une des modifications faisant l'objet d'un back-port.

Par conséquent, étant donné que le code peut être perdu si vous suivez aveuglément un ensemble de commandes pour résoudre cette situation, c'est pourquoi GIT vous invite à vous guider manuellement.

0
GuyPaddock