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

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

J'ai fait un rebase contre master de ma branche:

git rebase master

et j'ai 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.

Je suis donc allé dans mon éditeur préféré, j'ai corrigé le conflit d'une ligne, j'ai enregistré le fichier et j'ai fait un état git et j'ai obtenu la sortie suivante:

 # 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 statut git 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 - continuez, j'obtiens:

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

Je sais que je peux ignorer le correctif et continuer le rebase, mais je ne suis pas sûr si les modifications de PassengerContactHandler.java seront rebasées dans ma branche ou non.

donc je ne suis 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 m'est arrivé à nouveau:

Ça m'est arrivé de 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

Cela se produit car lors de la résolution d'un conflit, vous avez supprimé tout le code du correctif appliqué à la branche sur laquelle vous rebasez. Utilisez git rebase --skippour continuer.

Un peu plus de détails:

Normalement, lors de la résolution d'un conflit pendant le rebasage, vous éditerez le fichier en conflit, en conservant tout ou partie du code du correctif actuellement appliqué à la branche sur laquelle vous rebasez. Après avoir réparé 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 / fichier / en conflit

git rebase --continue fonctionnera correctement dans cette situation.

Parfois, cependant, lors de la résolution du conflit, vous supprimez tout dans votre nouveau correctif, 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 n'affichera aucune ligne verte affichant les fichiers modifiés. Maintenant, si tu fais

git rebase --continue

git se plaindra avec

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

Ce que git veut réellement que vous fassiez dans cette situation, c'est d'utiliser

git rebase --skip

pour sauter le patch. Auparavant, je ne faisais jamais cela, comme je n'étais toujours pas sûr de ce qui serait réellement ignoré si je le faisais, ce n'était pas évident pour moi ce que signifiait vraiment «sauter ce patch». Mais si vous n'obtenez pas de ligne verte avec

modifié: votre / fichier / en conflit

après avoir modifié le fichier en conflit, l'ajouter et avoir effectué l'état de git, vous pouvez être à peu près sûr d'avoir supprimé tout le correctif, et vous pouvez à la place utiliser

git rebase --skip

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 de fichiers restants dans vos dossiers de référentiel)

Semble être un bogue dans Git 1.7

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

Fondamentalement, cela devrait fonctionner, si vous faites un

git diff

après avoir résolu vos conflits et ensuite

git rebase --continue

devrait marcher.

J'ai reçu cet avertissement lorsque j'avais des fichiers non mis en scène. Assurez-vous que vous ne disposez d'aucun fichier non organisé. Si vous ne souhaitez pas que les fichiers non créés soient modifiés, supprimez les

git rm <filename>  

Essayez de l'exécuter dans votre ligne de commande:

$ git mergetool

Devrait faire apparaître un éditeur interactif vous permettant de résoudre les conflits. Plus facile que d'essayer de le faire manuellement, et git reconnaîtra également lorsque vous effectuez la fusion. Évitera également les situations dans lesquelles vous ne fusionnez pas complètement par accident, ce qui peut arriver lorsque vous essayez de le faire manuellement.

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

Vous avez manqué un conflit de fusion dans AssetsLoader.java. Ouvrez-le et recherchez les marqueurs de conflit (">>>>", "====", "<<<<<"), puis faites à nouveau git add. Faites un 'git diff --staged' si vous avez du mal à le trouver.

Je viens d'avoir ce problème, et même si je pense qu'il pourrait y avoir plusieurs causes, voici la mienne ...

J'avais un hook git pre-commit qui rejetait les commits sous certaines conditions. C'est bien lors de la validation manuelle, car cela affichera la sortie du hook, et je peux soit le corriger, soit choisir de l'ignorer en utilisant commit --no-verify.

Le problème semble être que lors du rebasage, rebase --continue appellera également le hook (afin de valider le dernier épisode de modifications). Mais rebase n'affichera pas la sortie du hook, il verra simplement qu'il a échoué, puis crachera une erreur moins spécifique en disant `` Vous devez éditer tous les conflits de fusion, puis les marquer comme résolus à l'aide de git add ''

Pour résoudre ce problème, mettez en scène toutes vos modifications, et au lieu de faire 'git rebase --continue', essayez un 'git commit'. Si vous souffrez du même problème de hook, vous devriez alors voir les raisons de son échec.

Fait intéressant, bien que git rebase n'affiche pas la sortie de git hook, il accepte un --no-verify pour contourner les hooks.

Une fois que vous avez corrigé vos modifications, vous pourriez oublier d'exécuter 'git add -A'

git add -A
git rebase --continue

Je viens de tomber sur le problème. Je ne voudrais pas git rebase --skip car git statusmontrer clairement les modifications échelonnées, ce que je souhaitais conserver. Bien que j'aie eu quelques fichiers supplémentaires qui sont venus de manière inattendue. J'ai résolu avec

git checkout .

pour supprimer les modifications non marquées, puis git rebase --continueréussi.