Git rebase --continue se plaint même lorsque tous les conflits de fusion ont été résolus.

Question

Je suis confronté à un problème que je ne sais pas comment résoudre.

J'ai fait un rebasement sur master à partir de ma branche :

git rebase master

et j'ai obtenu l'erreur suivante

 First, rewinding head to replay your work on top of it...
 Applying: checkstyled.
 Using index info to reconstruct a base tree...
 Falling back to patching base and 3-way merge...
 Auto-merging AssetsLoader.java
 CONFLICT (content): Merge conflict in AssetsLoader.java
 Failed to merge in the changes.
 Patch failed at 0001 checkstyled.

J'ai donc utilisé mon éditeur favori, corrigé le conflit d'une ligne, sauvegardé le fichier et fait un statut git pour obtenir le résultat suivant :

 # Not currently on any branch.
 # Changes to be committed:
 #   (use "git reset HEAD <file>..." to unstage)
 #
 #  modified:   PassengerContactHandler.java
 #
 # Unmerged paths:
 #   (use "git reset HEAD <file>..." to unstage)
 #   (use "git add/rm <file>..." as appropriate to mark resolution)
 #
 #  both modified:      AssetsLoader.java
 #

J'ai fait un git add AssetsLoader.java et un git status et j'ai obtenu ce qui suit :

 # Not currently on any branch.
 # Changes to be committed:
 #   (use "git reset HEAD <file>..." to unstage)
 #
 #  modified:   AssetsLoader.java
 #  modified:   PassengerContactHandler.java
 #

et quand j'ai fait git rebase --continue j'ai obtenu :

git rebase --continue
You must edit all merge conflicts and then
mark them as resolved using git add

Je sais que je peux sauter le patch et continuer le rebasement, mais je ne suis pas sûr que les changements dans PassengerContactHandler.java seront rebasés dans ma branche ou pas.

Je ne suis donc pas sûr, comment dois-je procéder ?

Edit : Se pourrait-il que le fichier avec le conflit résolu soit exactement comme la version originale ?

Merci beaucoup, Lucas

Edit, ça vient de m'arriver à nouveau :

Ça vient de m'arriver à nouveau,

(307ac0d...)|REBASE)$ git status
# Not currently on any branch.
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   assets/world/level1/Level-1.xml
#   modified:   George.java
#   modified:   DefaultPassenger.java
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   mb-art/originalAssets/27dec/

((307ac0d...)|REBASE)$ git rebase --continue

You must edit all merge conflicts and then
mark them as resolved using git add

git --version

git version 1.7.1

Answer 1

Cela se produit parce que lorsque vous corrigez un conflit, vous supprimez tout le code du patch qui est appliqué à la branche sur laquelle vous rebasez. Si vous êtes sûr d'avoir ajouté toutes vos modifications : Utilice git rebase --skip pour continuer.

Un peu plus de détails :

Normalement, lorsque vous corrigez un conflit pendant le rebasement, vous éditez le fichier en conflit, en conservant une partie ou la totalité du code du patch actuellement appliqué à la branche sur laquelle vous rebasez. Après avoir corrigé le patch et fait

git add your/conflicted/file
git status

vous obtiendrez une ligne (généralement verte) montrant le fichier modifié

modifié : votre/conflictuel/fichier

git rebase --continue fonctionnera très bien dans cette situation.

Parfois, cependant, lors de la résolution du conflit, vous supprimez tout dans votre nouveau patch, ne gardant que le code de la branche sur laquelle vous avez rebasé. Maintenant, lorsque vous ajoutez le fichier, il sera exactement comme celui sur lequel vous avez essayé de rebaser. git status ne montrera aucune ligne verte affichant les fichiers modifiés. Maintenant, si vous faites

git rebase --continue

git se plaindra avec

Aucun changement - avez-vous oublié d'utiliser 'git add' ?

Si vous êtes sûr d'avoir ajouté tous vos changements ce que git veut réellement que vous fassiez dans cette situation est d'utiliser

git rebase --skip

pour sauter le patch. Auparavant, je ne le faisais jamais, car je n'étais jamais sûr de ce qui serait réellement sauté si je le faisais, il n'était pas évident pour moi de savoir ce que "sauter ce patch" signifiait vraiment. Mais si vous n'obtenez pas de ligne verte avec

modifié : votre/conflictuel/fichier

après avoir édité le fichier en conflit, en l'ajoutant et en exécutant git status, vous pouvez être sûr d'avoir supprimé l'intégralité du patch, et vous pouvez à la place utiliser

git rebase --skip

pour continuer.

Le message original disait que cela fonctionne parfois :

git add -A
git rebase --continue
# works magically?

... mais ne vous fiez pas à cela (et assurez-vous de ne pas ajouter les fichiers restants dans vos dossiers de dépôt).

Answer 2

Il semble qu'il s'agisse d'un bogue dans Git 1.7.

Voici un bon article sur la façon de résoudre ce problème. .

En gros, cela devrait fonctionner, si vous faites un

git diff

après avoir résolu vos conflits et ensuite

git rebase --continue

devrait fonctionner.

Answer 3

J'ai reçu cet avertissement lorsque j'avais des fichiers non organisés. Assurez-vous que vous n'avez pas de fichiers non organisés. Si vous ne voulez pas que les fichiers non gérés soient modifiés, supprimez les modifications avec la commande

git rm <filename>

Answer 4

Après avoir résolu le conflit, assurez-vous que les fichiers modifiés sont ajoutés à vos fichiers indexés. Cela a résolu le problème pour moi.

Answer 5

Une fois que vous avez corrigé vos modifications, vous pouvez oublier de lancer 'git add -A'.

git add -A
git rebase --continue