Le renommage de Git de index.lock en index a échoué
En utilisant le client Windows GitHub, j’ai effectué un sync pour extraire les modifications à distance de mon ordinateur local, mais avant de terminer la synchronisation, j’ai manqué d’espace disque et la synchronisation a échoué. Maintenant, il me semble avoir un tas de changements locaux qui sont en réalité des changements qui ont été extraits d’Origin. J'ai essayé de lancer git pull mais j'ai:
C:\Users\Tom\SourceLog [master +4 ~26 -0 !]> git pull
Updating b3a86e1..5afd74f
error: Your local changes to the following files would be overwritten by merge:
SourceLog.Interface/IChangedFile.cs
SourceLog.Interface/ILogEntry.cs
...
Please, commit your changes or stash them before you can merge.
error: The following untracked working tree files would be overwritten by merge:
Lib/MSBuildExtensionPack/4.0.6.0/Ionic.Zip.dll
Lib/MSBuildExtensionPack/4.0.6.0/MSBuild.ExtensionPack.dll
...
Aborting
Alors maintenant, j'essaie d'écarter les changements locaux mais je reçois:
C:\Users\Tom\SourceLog [master +4 ~26 -0 !]> git checkout -- .
Rename from '.git/index.lock' to '.git/index' failed. Should I try again? (y/n) y
Rename from '.git/index.lock' to '.git/index' failed. Should I try again? (y/n) n
fatal: unable to write new index file
Comment puis-je nettoyer cela? (Je n'ai eu aucun changement local avant de commencer la synchronisation.)
Mettre à jour
Je n'arrive pas à remettre la tête à zéro ..
C:\Users\Tom\SourceLog [master +4 ~0 -0 !]> git reset head
Rename from '.git/index.lock' to '.git/index' failed. Should I try again? (y/n) y
Rename from '.git/index.lock' to '.git/index' failed. Should I try again? (y/n) n
error: Could not write new index file.
fatal: Could not reset index file to revision 'head'.
On dirait que le processus suivant avait un verrou sur le fichier .git\index:
ssh-agent.exe
C:\Users\Tom\AppData\Local\GitHub\PortableGit_8810fd5c2c79c73adcc73fd0825f3b32fdb816e7\bin\ssh-agent.exe
J'ai tué le processus et exécuté git reset HEAD et il semble que je sois revenu à la normale maintenant.
Dans mon cas, cela était dû à l'utilisation du même référentiel Git à partir d'invites de commande admin et non-admin. Lorsque le dernier git pull provenait de cmd d’administrateur, la index était créée par celle-ci et que la cmd non-administrateur ne disposait pas des autorisations suffisantes pour le modifier.
Ma solution était de recréer la index (tout en gardant l’arbre de travail intact):
del .git\index
git reset --mixed head
Je voyais ce message Rename from '.git/index.lock'... lors d'une tentative d'exécution
git checkout -b my-branch
Le correctif pour moi était d’exécuter la ligne de commande en tant que admin.
Plus précisément, j'utilisais l'excellente application cmder en tant que non-administrateur, ce qui a entraîné l'affichage du message de changement de nom. En exécutant cmder en tant qu'administrateur, puis en effectuant une nouvelle commande, cela a bien fonctionné.
Git 2.10 (T3 2016, 4 ans plus tard) devrait améliorer la situation sous Windows
Voir commit 05d1ed6 (23 août 2016) de Ben Wijen (Ben) .
mingw: s'assurer que les descripteurs de fichiers temporaires ne sont pas hérités par les processus enfantsLorsque l'index est verrouillé et que les processus enfants héritent du descripteur sur ledit verrou et le processus parent veut supprimer le verrou avant le le processus enfant se termine, il y a un problème sous Windows: cela ne fonctionnera pas parce que les fichiers ne peuvent pas être supprimés si un processus en contient un.
Le symptôme:
Rename from 'xxx/.git/index.lock' to 'xxx/.git/index' failed.
Should I try again? (y/n)
La génération de processus enfants avec
bInheritHandles==FALSEne fonctionnerait pas car aucun descripteur de fichier ne serait hérité, pas même les descripteurshStdXxxdansSTARTUPINFO(stdin/stdout/stderr).Ouvrir chaque fichier avec
O_NOINHERITne fonctionne pas non plus, comme par exemple.git-upload-packattend les descripteurs de fichiers hérités.Cela nous laisse le seul moyen de sortir: créer des fichiers temporaires avec l'indicateur
O_NOINHERIT. Cet indicateur est cependant spécifique à Windows.
Pour nos besoins, cela équivaut àO_CLOEXEC(qui n'existe pas sous Windows), donc ouvrons simplement les fichiers temporaires avec leO_CLOEXECet mappe cet indicateur surO_NOINHERITsous Windows .
J'ai supprimé index et index.lock (dans le dossier .git) et ai exécuté git checkout . pour annuler les modifications et résolu, mais si je voulais valider les modifications, j'aurais exécuté git add -A après git commit -m "description"
Tuez le processus qui verrouille le fichier ou, s’il s’agit d’un nouveau référentiel, supprimez le dossier .git rm -rf .git et recommencez avec git init
J'ai eu un problème similaire avec Git. La solution pour moi consistait à supprimer la solution localement via Windows Explorer, puis à cloner à nouveau le référentiel. Cela supprimait tous les fichiers stockés localement sur ma machine et entraînait la
Rename from '.git/..' to '.git/..' failed. Should I try again? (y/n) y
s'en aller. Après avoir cloné le référentiel, j'ai réessayé ma commande (GIT COMMIT dans mon cas) et l'échec ne s'est pas reproduit.
Le problème est survenu lorsque j'ai tenté de résoudre un conflit de fusion suite à la fusion d'une branche de fonctionnalité dans la branche de développement.
Cela peut être un bon problème, essayez d’exécuter votre terminal en tant qu’administrateur plutôt qu’utilisateur. A travaillé pour moi
J'utilise Tortoise Git. Je viens d'ouvrir un nouvel explorateur Windows et cela a été corrigé. (Pour la ligne de commande, Git peut simplement ouvrir un nouveau shell).
J'ai eu cette erreur plusieurs fois de suite en exécutant git reset HEAD dans un projet stocké dans un dossier Google Drive, mais après quelques minutes, le problème a disparu.
Pour ignorer les modifications locales, allez à
git reset HEAD
Ensuite, vérifiez votre ancien commit, supprimez le nouveau et tirez à nouveau.
git checkout "hashOld"
git branch -d "hashNew"
git pull