Git 'fatal: impossible d'écrire un nouveau fichier d'index'
J'ai vu beaucoup d'autres sujets à ce sujet et ils ne m'aident pas.
J'ai un repo très simple - deux fichiers JavaScript. J'ai plus de 100 Go sur Macbook. Lorsque j'essaie de déplacer les fichiers dans un sous-répertoire et de mettre en scène localement les modifications apportées ...
fatal: impossible d'écrire un nouveau fichier d'index
Cela se produit si je fais toutes les actions dans le terminal ou si j'utilise une interface graphique comme SourceTree. En outre, l'un des fichiers devient verrouillé et je ne peux pas supprimer le répertoire de travail tant que je ne me suis pas déconnecté puis reconnecté.
Pourquoi cela arrive-t-il? Est-ce que le verrou empêche quelque chose de se mettre en scène? Si oui, comment puis-je déverrouiller le fichier du problème sous OS X? Le dépôt à distance est Google Code, si cela fait une différence, bien que je ne pousse pas encore vers la télécommande. Tout est local.
Dans mon cas, le disque était saturé, je devais donc supprimer des fichiers du disque dur pour libérer de l'espace.
J'ai le même problème depuis quelques jours. Fondamentalement, à mon insu, le référentiel entier avait été déplacé vers un nouveau système de fichiers. Lorsque j'ai essayé d'exécuter git status, il était soudainement signalé que tous les fichiers du référentiel avaient été mis à jour.
Solutions possibles
Donc, après beaucoup de recherches sur Google, j'ai essayé ce qui suit:
- changer les permissions .git (même problème)
- modification des autorisations .git/index (même problème)
- git ajoutant toutes les modifications à valider (même problème)
- git-rm-ing fichiers supprimés, car ils signalaient des erreurs de nom de fichier trop longues (même problème)
- git reset (soft | Head | Hard) (même problème)
- git clean (même problème)
- désactiver Windows Defender (même problème)
- mise à jour de git (même problème)
- différents clients git (j'utilise gitbash) (même problème)
- boire 2 cafés au lieu de 1 (même problème)
tl: dr - solution sale
La seule chose qui a réussi à résoudre le problème a été de copier le fichier d'index, de supprimer l'original et de renommer la copie.
Je sais que ce n’est pas vraiment une "solution", mais que cela fonctionne magiquement> <, avec tous les fichiers/branches intacts. Si quelqu'un sait pourquoi cela pourrait avoir du travail, dites-le.
J'ai eu le même problème sur un Mac. Cela semble être causé par les ACL du système de fichiers. Essayez chmod -RN /path/to/repo pour effacer les ACL. Après cela, j'ai pu valider des modifications. En utilisant l’astuce pour copier le fichier d’index, supprimez l’original et déplacez la copie pour obtenir le même résultat.
Dans mon cas, interrompre la synchronisation de Dropbox a résolu le problème.
Si vous avez configuré votre github dans un type de service de synchronisation en ligne, tel que Google Drive ou Dropbox, essayez de désactiver la synchronisation car le même problème se présentait et cela fonctionnait pour moi.
Cela a fonctionné pour moi:
rm -f ./.git/index.lock
Il m'est arrivé que le fichier .git/index était utilisé par un autre processus (mon serveur Web de développement local). J'ai arrêté le processus et puis cela a fonctionné.
ACL (en quelque sorte) était attaché à tous les fichiers du dossier .git.
Vérifiez-le avec ls -le dans le dossier .git.
Vous pouvez supprimer la liste de contrôle d'accès avec chmod -N (pour un dossier/fichier) ou chmod -RN (récursif)
Dans mon cas, c’était un concurrent simultané EGit. Après avoir redémarré Eclipse, cela fonctionne normalement.
Dans mon cas, la solution consistait simplement à ajouter une autorisation au nouvel utilisateur.
Lorsque j'ai installé un nouveau système d'exploitation, déplacé mon dépôt et qu'il affichait cette erreur exacte, j'ai sélectionné le dossier racine, puis ajouté l'utilisateur authentifié pour vérifier tout 
Je pense que certaines solutions de sauvegarde en arrière-plan, telles que Google Backup et Sync, bloquent l'accès au fichier d'index. J'ai fermé l'application et Sourcetree n'a eu aucun problème. On dirait que Dropbox fait de même (@tonymayoral).
Fermer le code de Visual Studio (dans mon cas, une tâche d’arrière-plan de téléchargement automatique s’exécutant sur la sauvegarde de fichier) a résolu le problème pour moi.
Crédit pour la solution: mon ami et collègue Arnel.
J'ai eu le même problème. J'ai redémarré mon ordinateur et le problème a été résolu.
Si vous utilisez une boîte de dialogue Windows, assurez-vous que le programme utilisé, qu'il s'agisse de l'arbre source ou d'un terminal git, s'exécute en tant qu'administrateur. Je recevais le même message d'erreur exact. Vous pouvez soit cliquer avec le bouton droit sur le programme à exécuter en tant qu'administrateur, soit modifier ses propriétés pour toujours l'exécuter en tant qu'administrateur.
avez-vous essayé 'git add.' . tous les changements seront-ils? (vous pouvez supprimer les fichiers inutiles ajoutés en réinitialisant git HEAD)
Ne pas avoir assez d'espace est un problème. Nettoyer et réessayer
Problème: Lorsque je vérifiais certains fichiers modifiés dans git, j'ai cette erreur… .. Je rencontrais deux utilisateurs ABC et XYZ. les fichiers ont un uid: gid of ABC mais il n’a pas accès à git et essaie de récupérer les fichiers avec le même.
La solution que j'ai essayée: XYZ, c'est d'avoir un accès git, d'essayer de vérifier les fichiers avec Sudo et ça a marché .. !!
J'ai eu ce problème en utilisant GitExtensions sur Windows. Fixé en accordant une permission complète à l'utilisateur actuel (moi) sur le dossier contenant le référentiel.
Une autre fois, même si je recevais l'erreur de Git Extensions, je pouvais valider les mêmes fichiers à partir de Visual Studio 2015.
Une autre fois, j'ai dû supprimer le fichier "index" du dossier .git
SI VOUS OBTENEZ CETTE PÉRIODE DE RECONNAISSANCE:
Ceci est probablement dû à un logiciel qui verrouille le fichier d'index de votre référentiel, tel qu'un logiciel de sauvegarde, des antivirus, des IDE ou d'autres clients git.
Dans la plupart des cas, la serrure n'est que pour un bref instant et elle survient donc par manque de timing et de malchance.
Cependant, git rebase --continue se plaindra de la validation de la prochaine commande:
The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:
git commit --allow-empty
Pour résoudre ce problème, exécutez simplement git reset et essayez à nouveau avec git rebase --continue.
Voici ce qui a fonctionné pour moi:
Le contexte:
Construire un projet sur un serveur
git statusrenvoie unHEAD detached at <commit-SHA>Quelle que soit l'opération que j'ai faite localement, j'ai eu cette erreur. Plus précisement:
- git checkout
- git reset HEAD --hard
Solution
- Il suffit de supprimer le fichier
<work-dir>/.git/index. - Un
git statusindiquerait que tous les fichiers du projet ne font pas l'objet d'un suivi (pas de surprise ici). git reset HEAD --hard- Retour à
HEAD detached at <commit-SHA>lorsque vous faites ungit status, mais vous devriez alors pouvoir git checkout <some-branch>
et vous êtes de retour sur la bonne voie!
!! IMPORTANT !!
Cela ne fonctionne que parce que je suis "merly" bâtiment. Aucune modification précieuse n'a été effectuée sur le code. Si vous êtes réellement en "dev-time", alors je vous recommande de sauvegarder votre travail d’abord ou de choisir une autre méthode.
J'espère que ça va aider :).
Mon cas est un peu intéressant:
J'exécute git log pour vérifier un commit, puis je ne l'ai pas quitté correctement, j'appuie sur ctrl + c pour le quitter.
Ensuite, l'index semble avoir été verrouillé. Je lance donc à nouveau git log, puis appuie sur Q pour le quitter.
Problème résolu. :)
Ce problème peut être causé par .git\index verrouillé par un processus.
Le lien Découvrez quel processus verrouille un fichier ou un dossier dans Windows spécifie l'approche suivante pour trouver un fichier verrouillé:
SysInternals Process Explorer - Allez à Rechercher> Trouver une poignée ou une DLL. Dans la zone de texte "Handle or DLL", tapez le chemin du fichier (par exemple, "C:\chemin\to\fichier.txt") et cliquez sur "Rechercher". Tous les processus qui ont un handle ouvert sur ce fichier doivent être listés.
Utilisez l'approche ci-dessus pour rechercher le processus verrouillé .git\index, puis arrêtez l'exécutable verrouillé. Cela devrait résoudre le problème.
Par exemple, Process Explorer Search indique que mon .git\index a été verrouillé par vmware-vmx.exe. La suspension de la machine virtuelle VMWare Player (qui a accédé au référentiel git via un dossier partagé) a résolu le problème.