Obtenir une erreur fatale dans git pour les entrées à plusieurs étapes


241

Utiliser Git version 2.2.0 avec le moteur de jeu Unity sur OS X, et je voulais valider mon code. J'ai tout ajouté et je n'ai pas reçu de message d'erreur. puis validez -m et obtient ce message d'erreur:

fatal: multiple stage entries for merged file 'Assets/Prefabs/Resources'

Ne le remarquant pas, j'ai poussé, cela n'a pas donné de message d'erreur, en fait, Everything up-to-date j'ai donc vérifié bitbucket (où se trouve le dépôt) et cela n'a pas montré mon commit. J'ai donc vérifié mon journal local et cela ne montre pas non plus mon commit.

J'ai cherché dans google une réponse ... et rien. quelle est cette erreur? et comment puis-je y remédier?


Quelle version de git ou d'outil utilisez-vous? Il y a eu un fil récent sur la liste des développeurs sur l'amélioration de la vérification des entrées à plusieurs étapes. news.gmane.org/gmane.comp.version-control.git
Philip Oakley

Sonne probablement que la vérification supplémentaire dans 2.2.0 peut être impliquée. "Assurez-vous que les entrées non fusionnées sont supprimées" 12 août par Jaime Soriano Pastor, peut être un fil pour commencer.
Philip Oakley

4
alors pourquoi cela se produit-il?
Charlie Parker

il suffit de faire une modification fictive dudit fichier et de «valider et synchroniser».
sajanyamaha

Remarque: voir également stackoverflow.com/a/51919644/6309
VonC

Réponses:


381

La première solution, qui semble fonctionner avec les versions récentes de Git (2.3+, Q2 + 2015) est mentionné dans la subvention de plus à jour réponse :

  1. Supprimer l'index

    $ rm .git/index
    
  2. Tout ajouter

    $ git add -A
    
  3. Commettre

    $ git commit -a
    

Réponse originale (fin 2014)
La solution de contournement habituelle consiste à:

  • cloner à nouveau le référentiel distant dans un nouveau référentiel local
  • ajoutez les modifications du premier dépôt au second:

    $ cd /patH/to/second/cloned/repo
    $ git --work-tree=/path/to/first/repo add .
    

Vous pouvez voir ce message d'erreur dans read-cache.c, discuté dans ce correctif (" read-cache.c: Assurez-vous que les entrées non fusionnées sont supprimées "), et introduit dans le commit Git 2.2 .
Comme c'est si récent, il est possible que la rétrogradation de Git en 2.1 soit suffisante pour ne pas être affectée par ce patch.

L' OP Daniel Toebe ajoute dans les commentaires :

Le problème s'est produit sur mon macbook, qui a décidé d'échouer sur moi, et un autre incident informatique m'a mis beaucoup de retard sur mes projets.


@sharpner il est possible que ce soit un bug ou un effet secondaire de ce patch dans votre cas.
VonC

1
Désolé pour la réponse tardive ... Le problème est survenu sur mon macbook, qui a décidé d'échouer sur moi, et un autre incident informatique m'a mis loin derrière sur mes projets.
Daniel Toebe

1
@DanielToebe bonne rétroaction. Je l'ai inclus dans la réponse pour plus de visibilité.
VonC

Je viens de tomber sur le même, après une tentative degit commit -c sha
Chris Leishman

2
Pour tout intéressé, cela m'est arrivé parce que je modifiais accidentellement un fichier dans mon dossier .git au lieu du fichier lui-même.
ostler.c

166

Je crois avoir rencontré ce problème car j'ai ajouté et validé des modifications, puis supprimé un fichier que je venais de valider. Si cela semble similaire à votre cas, je vous recommande de suivre ce qui suit pour enregistrer le re-clonage et ajouter manuellement vos modifications.

J'ai pu résoudre ce problème en supprimant le fichier .git / index dans mon référentiel, similaire à ce que @slider a suggéré (je pense qu'il a mal saisi le chemin).

rm .git/index

Ensuite, j'ai dû ajouter et valider mes modifications locales à nouveau

git add -A
git commit -m "..."

J'ai alors pu pousser à distance.

Qu'est-ce que l'indice git et comment est-il pertinent?

Quel est le problème avec l'indice Git?

Le «index» git est l'endroit où vous placez les fichiers que vous souhaitez valider dans le référentiel git.

Avant de «valider» (archiver) des fichiers dans le référentiel git, vous devez d'abord placer les fichiers dans «l'index» git.

Je crois qu'en supprimant ce fichier, git ré-indexera le dépôt, en créera un nouveau et vous êtes prêt à partir. Il résout ce problème car le référentiel local est réindexé sans le fichier que j'ai supprimé qui a causé tout le tapage.

Edit: Il semble que cela soit lié à Mac (basé sur les commentaires), donc si cela aide, je suis sur OSX 10.10 et git version 2.3.4 installé via brew.


1
Oui, cela a fonctionné et merci pour l'explication. Une mise en garde ici avant de procéder consiste à cacher, déplacer ou supprimer tous les fichiers auxquels vous n'avez pas ajouté la liste de modifications par défaut actuelle. Ils seront aspirés avec legit add -A
Kirby

4
Confirmez cela sur Mac OS X Yosemite. Arrivé en travaillant dans Android Studio, bien qu'il n'y ait pas de scénario reproductible spécifique ..
Drew

4
Cela devrait être la bonne réponse car cela fonctionne et il a une meilleure explication. Cela m'est juste arrivé aussi.
Jared Burrows

1
A aussi fonctionné pour moi. L'ajout de la racine de contrôle de version dans IntelliJ l'a bousculé, mais l'utilisation de l'index git a bien fonctionné. Merci pour l'explication @grant.
Andrew Eells

1
J'ai également eu ce problème lorsque IntelliJ fonctionnait en arrière-plan alors que je faisais des modifications avec vim. Je pense qu'il y avait une condition de course git. (En fait, je pense qu'il y en a beaucoup.) La fermeture d'IntelliJ, la suppression de l'index et la reprise de mon travail ont très bien fonctionné.
Robert Fischer

119

Pour projet

rm .git/index
git reset

après avoir supprimé l'index, vous devez le recréer par git reset

Pour le sous-module:

Accédez au dossier principal du projet

rm .git/modules/your_project_structure/index
git reset --hard HEAD

4
Le git s'est réinitialisé après la suppression de l'index. Merci! Si vous ne réinitialisez pas chaque fichier sera nouveau dans l'index, il faut donc l'ajouter. La réinitialisation reconstruira l'index, semble-t-il. Même si je ne comprends pas comment git peut reconstruire l'index, sans index?
JosFabre

1
@JosFaber Parce que l'index n'est pas l'historique des validations. En fait, c'est une structure d'assistance "redondante". Voir schacon.github.io/gitbook/7_the_git_index.html Ainsi, il peut être complètement reconstruit en comparant l'arbre de travail et HEAD. Et c'est exactement ce que fait git reset. La page de manuel dit: ... réinitialiser les entrées de copie de <tree-ish> dans l'index ...
farincz

2
Je vous remercie! Sans la réinitialisation de git, il voulait que je rajoute tous les fichiers déjà dans le référentiel.
Robert Bernstein

1
J'utilise sourcetree sur mon mac. J'ai supprimé manuellement le .git / index, puis sélectionné le dernier bon commit, cliqué avec le bouton droit, sélectionné réinitialisé le maître (dans mon cas) à ce commentaire - puis choisi l'option mixte qui laisse mon travail en bon état. J'ai alors pu faire un commit de mon travail actuel et tout va bien maintenant.
user216661

1
Le moyen le plus propre et le plus rapide!
h4rd4r7c0r3

29

Vous pouvez supprimer le fichier d'index Git de votre projet. À la racine de votre projet, exécutez la commande suivante:

rm .git/index

Après ça, ça marche.


3
Cela ne répond pas à la question. Veuillez étoffer cette réponse avec plus de détails.
ArtOfCode

N'a pas fonctionné pour moi rm: /.git/index: No such file or directoryMac OSX Yosemite; git 2.3.4 installé via homebrew
accordez

@grant Vous devez supprimer la barre oblique au début. ( rm .git/indexdans votre répertoire git).
ChristophLSA

2
@ChristophLSA merci - j'ai répondu avec une description de ce que fait cette action pour plus de clarté. Cette réponse peut-elle être mise à jour pour refléter le chemin approprié et informer les utilisateurs de ce que fait l'action?
accorder le

1
Je sais pourquoi ça marche. Le problème est dû à un index corrompu. J'ai rencontré ce problème lorsque j'ai corrompu l'index en modifiant le code dans IntelliJ lors de l'écriture d'un message de validation dans la ligne de commande. La suppression de l'index ne détruit pas vos modifications, elle les décompose simplement.
Pyrolistical

3

J'essaie une solution différente et cela fonctionne pour moi. Voici mes options

#cd .git
#rm index
#cd ..
#git add .

comme l'a dit @farincz, vous devez recréer à nouveau l'index en appelant git resetsinon cela vous donne fatal: Could not reset index file to revision 'HEAD' .
kuskmen

1

Si cela se produit dans un sous-module

Le fichier d'index se trouve dans le .gitrépertoire parent :

.git/modules/your_project_structure/index

Dans un sous-module, il n'y a pas de répertoires nommés .git(du moins dans le projet sur lequel je travaille), il n'y a qu'un.git lequel fichier qui vous indique (et git) où chercher le répertoire git de ce projet.

Le statut Git montre les changements que je n'ai pas faits

Après avoir supprimé les fichiers d'index et fait un git reset, je me suis retrouvé face à de nombreux changements inexplicables et une réinitialisation matérielle n'aidait pas.

Attention, vous perdrez toutes vos modifications, alors validez-les et appuyez sur avant de continuer.

L'index semblait corrompu, je l'ai donc supprimé avec les commandes suivantes.

git rm -rf --cached .
git reset --hard HEAD

0

Je viens de recevoir cette erreur avec le client de bureau Github (OSX). Tout ce que j'ai fait, c'est de quitter l'application et de la rouvrir, puis elle a commencé à fonctionner.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.