Git 'fatal: Impossible d'écrire un nouveau fichier d'index'

J'ai vu beaucoup d'autres fils à ce sujet et ils n'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 que j'obtiens ...

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. De plus, l'un des fichiers est verrouillé et je ne peux pas supprimer le répertoire de travail tant que je ne me déconnecte pas et ne me reconnecte pas.

Pourquoi cela arrive-t-il? Le verrou empêche-t-il quelque chose de se mettre en scène? Si oui, comment puis-je déverrouiller le fichier problématique sous OS X? Le dépôt distant 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 à court d'espace, j'ai donc dû supprimer des fichiers du disque dur pour libérer de l'espace.

J'ai eu ce même problème ces derniers jours. Fondamentalement, à mon insu, tout le dépôt 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 chaque fichier du dépôt avait été mis à jour.

Solutions possibles

Donc, après beaucoup de recherches sur Google, j'ai essayé ce qui suit:

• modification des autorisations .git (même problème)
• modification des autorisations .git / index (même problème)
• git ajout de toutes les modifications à commit (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 d'un (même problème)

tl: dr - solution sale

La seule chose qui a réussi à résoudre le problème était 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 maintenant ça fonctionne comme par magie> <, avec tous les fichiers / branches intacts. Si quelqu'un sait pourquoi cela pourrait fonctionner, dites-le.

Dans mon cas, la suspension de la synchronisation de Dropbox a résolu le problème

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/repod'effacer les ACL. Après avoir fait cela, j'ai pu valider des changements. En utilisant l'astuce pour copier le fichier d'index, supprimer l'original et déplacer la copie vers l'arrière a obtenu le même résultat.

Si vous avez configuré votre github dans une sorte de service de synchronisation en ligne, tel que Google Drive ou Dropbox, essayez de désactiver la synchronisation car le service de synchronisation tente de lire / écrire dans le fichier alors que github essaie de faire de même, ce qui fait que github ne fonctionne pas correctement.

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 cela a fonctionné.

La fermeture de Visual Studio Code (qui, dans mon cas, a un travail d'arrière-plan de téléchargement automatique en cours d'exécution sur l'enregistrement de fichiers) a résolu le problème pour moi.

Le mérite de la solution: mon ami et collègue Arnel.

Cela a fonctionné pour moi:

rm -f ./.git/index.lock

Dans mon cas, la solution consistait uniquement à ajouter une autorisation au nouvel utilisateur.

Lorsque j'ai installé un nouveau système d'exploitation, déplacé mes dépôts et qu'il montrait cette erreur exacte, j'ai sélectionné le dossier racine puis ajouté authentifié l'utilisateur pour tout vérifier

J'avais ACL (en quelque sorte) attaché à tous les fichiers dans le dossier .git.

Vérifiez-le ls -ledans le dossier .git.

Vous pouvez supprimer l'ACL avec chmod -N(pour un dossier / fichier) ou chmod -RN(récursif)

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. Il semble que Dropbox fasse de même (@tonymayoral).

Dans mon cas, c'était un EGit en cours d'exécution simultanée. Après avoir redémarré eclipse, cela fonctionne comme d'habitude.

Si vous êtes sous Windows, assurez-vous que le programme que vous utilisez, qu'il s'agisse de Source Tree ou d'un terminal git, s'exécute en tant qu'administrateur. J'obtenais exactement le même message d'erreur. Vous pouvez faire un clic droit sur le programme à exécuter en tant qu'administrateur ou modifier ses propriétés pour toujours s'exécuter en tant qu'administrateur.

Ne pas avoir assez d'espace est un problème. Nettoyez et réessayez

J'ai eu le même problème. J'ai redémarré mon ordinateur et le problème a été résolu.

avez-vous essayé 'git add.' . ce sera tous les changements? (vous pouvez supprimer les fichiers ajoutés inutiles par git reset HEAD)

Le message d'erreur fatal: Unable to write new index filesignifie que nous n'avons pas pu écrire le nouveau contenu dans le fichier d'index git .git\index(voir ici pour plus d'informations sur git index). Après avoir examiné toutes les réponses à cette question, je résume les causes profondes suivantes:

• La taille du nouveau contenu dépasse la capacité disponible du disque. ( Solution : nettoyez les espaces disque)
• Les utilisateurs n'ont pas le droit d'accès à ce fichier. ( Solution : accordez la permission)
• Les utilisateurs ont l'autorisation mais .git\indexsont verrouillés par d'autres utilisateurs ou processus. ( Solution : déverrouillez le fichier)

Le lien Découvrir quel processus verrouille un fichier ou un dossier dans Windows spécifie l'approche suivante pour trouver le processus qui verrouille un fichier spécifique:

Explorateur de processus SysInternals - Accédez à Rechercher> Rechercher un handle ou une DLL. Dans la zone de texte "Handle ou DLL sous-chaîne:", saisissez le chemin du fichier (par exemple "C: \ chemin \ vers \ fichier.txt") et cliquez sur "Rechercher". Tous les processus qui ont une poignée ouverte pour ce fichier doivent être répertoriés.

Utilisez l'approche ci-dessus pour trouver le processus verrouillé .git\index, puis arrêtez l'exécutable de verrouillage. Cela déverrouille .git\index.

Par exemple, Process Explorer Search montre que .git\indexest verrouillé par vmware-vmx.exe. La suspension de la machine virtuelle VMWare Player (qui accédait au repo git via un dossier partagé) a résolu le problème.

SI VOUS OBTENEZ CECI PENDANT UN REMBOURSEMENT:

Cela est probablement dû au verrouillage du fichier d'index de votre dépôt par certains logiciels, tels que les logiciels de sauvegarde, les antivirus, les IDE ou d'autres clients git.

Dans la plupart des cas, le verrouillage n'est que pour un bref moment et cela se produit simplement par mauvais timing et par malchance.

Cependant, git rebase --continuese plaindra de la prochaine commande étant un commit vide:

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 resetet réessayez git rebase --continue.

Problème: lorsque j'ai extrait des fichiers modifiés dans git, j'ai obtenu cette erreur. J'avais deux utilisateurs ABC et XYZ. les fichiers ont uid: gid d'ABC mais il n'a pas d'accès git et essaie d'extraire les fichiers avec le même.

La solution que j'ai essayée: XYZ a un accès git, a essayé de vérifier des fichiers avec sudo et cela a fonctionné .. !!

Voici ce qui a fonctionné pour moi:

Le contexte:

1. Construire un projet sur un serveur

2. git status renvoie un HEAD detached at <commit-SHA>

3. 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

1. Fichier simplement supprimé <work-dir>/.git/index.
2. A git statusindiquerait que tous les fichiers du projet ne sont pas suivis (pas de surprise ici).
3. git reset HEAD --hard
4. Revenez à HEAD detached at <commit-SHA>quand vous faites un git status, mais alors vous devriez pouvoir
5. git checkout <some-branch>

et vous êtes de retour sur la bonne voie!

!! IMPORTANT !!

Cela fonctionne uniquement parce que je suis en train de construire "merly". 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 d'opter pour une autre méthode.

J'espère que cela aidera :).

J'ai eu ce problème en utilisant GitExtensions sur Windows. Correction en accordant une autorisation complète à l'utilisateur actuel (moi) sur le dossier contenant le dépôt.

Une autre fois, même si j'obtenais l'erreur des extensions Git, j'ai pu valider les mêmes fichiers à partir de Visual Studio 2015.

Une autre fois, j'ai dû supprimer le fichier "index" du dossier .git

Mon cas est un peu intéressant:

Je lance git log pour vérifier un certain commit, puis je ne l'ai pas quitté correctement, j'appuie sur ctrl + c pour le quitter.

Ensuite, l'index semble verrouillé. Je lance donc à nouveau git log, puis j'appuie sur Q pour le quitter.

Problème résolu. :)

Dans mon cas, c'était une nodemoninstance qui surveillait le système de fichiers pour les changements.