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 le maître de ma branche:
git rebase master
et a 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.
Alors je suis allé dans mon éditeur préféré, j'ai résolu le conflit d'une ligne, sauvegardé le fichier et fait un statut de git et obtenu 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 ajouter 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 - continue je reçois:
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 poursuivre la modification de la base, mais je ne sais pas si les modifications apportées à PassengerContactHandler.Java seront ou non modifiées dans ma branche.
donc je ne suis pas sûr, comment dois-je procéder?
Edit: Est-il possible que le fichier avec le conflit résolu soit exactement comme la version d'origine?
Merci beaucoup, Lucas
Edit, ça m'est encore arrivé:
Cela m'est encore arrivé,
(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 vous rebassez. Utilisation git rebase --skip continuer.
n peu plus de détails:
Normalement, lors de la résolution d'un conflit lors de la refonte de la base, vous modifierez le fichier en conflit, tout en conservant tout ou partie du code du correctif actuellement appliqué à la branche sur laquelle vous avez refait la base. 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/conflit/fichier
git rebase --continue fonctionnera bien dans cette situation.
Parfois, cependant, lors de la résolution du conflit, vous supprimez tout ce qui se trouve dans votre nouveau correctif, en ne conservant que le code de la branche sur laquelle vous vous êtes rebasé. Maintenant, lorsque vous ajoutez le fichier, ce sera exactement comme celui sur lequel vous avez essayé de vous baser. Le statut de git ne montrera aucune ligne verte affichant les fichiers modifiés. Maintenant, si vous le faites
git rebase --continue
git va se plaindre avec
Aucun changement - avez-vous oublié d'utiliser 'git add'?
Ce que git veut réellement que vous fassiez dans cette situation est d’utiliser
git rebase --skip
sauter le patch. Auparavant, je ne faisais jamais cela, car je ne savais toujours pas vraiment ce qui serait ignoré si je le faisais, il n'était pas évident pour moi de comprendre ce que "ignorer ce patch" signifiait vraiment. Mais si vous n’avez pas de ligne verte avec
modifié: votre/conflit/fichier
après avoir édité le fichier en conflit, l’ajouté et le statut git, vous pouvez être certain d’avoir supprimé le correctif complet et utiliser à la place
git rebase --skip
continuer.
La publication originale disait que cela fonctionne parfois:
git add -A git rebase --continue # works magically?
... mais ne comptez pas sur cela (et assurez-vous de ne pas ajouter de fichiers 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, puis
git rebase --continue
devrait marcher.
Essayez d'exécuter ceci 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 quand vous ferez la fusion. Cela é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.
Je viens d'avoir ce problème, et bien que je pense qu'il pourrait y avoir quelques causes, voici la mienne ...
J'avais un hook git pre-commit qui refusait les commits sous certaines conditions. Cela convient très bien lorsque vous validez manuellement, car il affichera la sortie du hook, et je peux soit le corriger, soit choisir de l'ignorer à l'aide de commit --no-verify.
Le problème semble être que lors du changement de base, rebase --continue appelle également le hook (afin de valider la dernière série de modifications). Mais rebase n'affichera pas la sortie du hook, il verra simplement que cela 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.
Vous avez manqué un conflit de fusion dans AssetsLoader.Java. Ouvrez-le et recherchez les marqueurs de conflit (">>>>", "====", "<<<<<"), puis effectuez une nouvelle addition. Faites un "git diff --staged" si vous avez du mal à le trouver.
Une fois le conflit résolu, assurez-vous que les fichiers modifiés sont ajoutés à vos fichiers intermédiaires. Cela a résolu le problème pour moi.
J'ai eu cet avertissement quand j'avais des fichiers non staged. Assurez-vous de ne pas avoir de fichiers non staged. Si vous ne souhaitez pas que les fichiers non modifiés soient modifiés, annulez-les avec git rm <filename>.