git problème: fatal: Impossible d'écrire dans le nouveau fichier d'index

j'ai juste couru dans la même situation, il s'est avéré que mon système était plein.

avez-vous accès en écriture .git (=pouvez-vous créer de nouveaux fichiers et éditer les fichiers existants)? Si non, alors ajuster les autorisations de fichier.

si vous avez des permissions d'écriture, il semble que vous ayez trouvé un bug. Vous pouvez essayer de récupérer par

1. créer un clone à partir de votre copie de travail actuelle
2. supprimer tous les fichiers de la copie de travail de clone
3. copiez tous les fichiers wc de votre copie de travail actuelle vers le clone (et ne copiez pas .git)
4. essayer de commettre quelque chose dans le clone.

lorsque la dernière étape fonctionne, vous avez besoin de configurer les branches distantes de votre repo actuel au clone, et ensuite vous pouvez utiliser le repo cloné comme nouvelle copie de travail.

J'utilisais Parallels avec Ubuntu sur mon Mac. Je pourrais le faire, mais pas ajouter. Je pense que le problème est que git add nécessite une synchronisation atomique avec la base de données Git sous-jacente. Et puisque le système de fichiers que j'utilisais était en fait sur mon Mac et que Parallels exportait depuis mon Mac via un réseau partagé. Je crois que cela signifie que git ne pouvait pas faire ce qu'il voulait. Déplacer les fichiers localement a résolu le problème (dans mon cas c'était facile puisque j'utilisais DropBox sur mon Mac, donc j'ai juste installé DropBox sur mon Ubuntu cours d'exécution Parallèles)

j'ai eu un problème similaire avec le lecteur réseau SFTP (gratuit). La solution est de remplir la boîte de dialogue "Supprimer la cible existante avant de la déplacer" qui se trouve dans les paramètres de profil du lecteur réseau SFTP.

j'ai pu arranger ça en entrant dans le .dossier git dans l'application initiée par git et la suppression de l'index.verrouiller/fichier d'index. J'ai dû réindexer toute l'application, mais ça a résolu le problème.

Si vous utilisez sshfs, ajouter l'option -o workaround=rename, comme décrit ici: http://alan.lamielle.net/2009/07/08/git-over-sshfs

j'aimerais souligner une autre cause de cette erreur

Si vous clonez un dépôt git qui contient un autre dépôt git (pas de sous-module), vous obtiendrez ce comportement.

J'espère que ça aidera quelqu'un.

j'ai eu le même problème. Je ne sais toujours pas la cause, mais ma solution est de supprimer l'index.verrouillage sudo rm -f index.lock, et puis j'en ai donné la permission d'écrire à l'index sudo chmod 777 index. Après cela, je suis capable de mettre en scène et de m'engager. Le problème, c'est que je dois faire ça presque toutes les fois où j'ai quelque chose à mettre en scène.

C'est vieux, mais la cause pour moi était Dropbox. Mon dépôt local était stocké dans mon dossier Dropbox, et j'ai dû mettre en pause la synchronisation de Dropbox avant de pouvoir terminer la commande.

j'ai eu un problème similaire. "git reset -- hard" a travaillé pour moi.

pour ajouter: étonnamment, certains plug-ins git fichier d'index de blocs. Mon Kepler Eclipse dispose d'un plug-in par défaut, qui met occasionnellement à jour certaines informations de Git repo, bloquant le fichier index pendant cette opération.

j'avais utilisé ce problème lors de l'utilisation de Git sur visual studio, et ma solution était d'exécuter visual studio comme administrateur

j'ai eu la même erreur parce que la sauvegarde de Google Drive et le client de synchronisation pour Windows n'avaient pas libéré un verrou sur deux fichiers dans ce dépôt. Après que le client sync eut terminé son travail, un travail de contournement a été effectué: Process Explorer -> Find -> Find handle ou DLL -> Close Handle.