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

J'ai déjà un projet qui a été géré sous git. J'ai récemment eu à faire au sol jusqu'à la reconstruction de l'ordinateur (mac OS X Snow Leopard), et le retour au projet, git peut suivre les modifications dans le projet, mais je ne peux pas sauver quoi que ce soit à git. Je reçois le message d'erreur dans le titre, lorsque j'essaie :

Dans-iMac-335:[app-name-obscured] apple$ git add app/models/*
fatal: Unable to write new index file

Quelle est la meilleure façon de se sortir de cette situation? Il y a un heroku version du dépôt de cela, mais il est très en décalage avec celui-ci. sans doute je pourrais utiliser un nouveau clone de base, et la mise à jour de chaque fichier, mais qui semble plus laborieux et sujettes à erreur.

Qu'est-ce que git cherche ici qu'il ne peut pas le trouver, et s'il y a un changement qui permettra de les restaurer?

BTW, les autorisations de fichier sont corrects à partir de ce que je peux dire - les fichiers sous le contrôle et la .git composants sont détenues par moi avec rw accès...

InformationsquelleAutor Dan Donaldson | 2010-09-28
  1. 62

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

    InformationsquelleAutor Timmy
  2. 4

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

    Si vous disposez des autorisations d'écriture, il semble que vous avez trouvé un bug. Vous pouvez essayer de récupérer par

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

    Lors de la dernière étape fonctionne, vous devez configurer la télécommande branches à partir de votre repo pour le clone, et puis vous pouvez utiliser la cloné pensions que votre nouvelle copie de travail.

    • Rudi est presque certainement droit. Même si le nom de ce compte sur votre machine ancienne et votre nouvelle machine est le même, c'est pas ce que OS X se soucie sous les couvertures, c'est l'UID qui compte. Comme Rudi suggéré, voir si vous pouvez apporter une modification à un fichier comme le .git/config sans avoir besoin de sudo. Si vous ne pouvez pas (ce qui je pense est le cas), alors la solution est probablement juste de sudo chown tout à votre nouvel utilisateur.
    • J'ai reçu récemment un nouveau Mac Book et avoir eu mon dépôt git sur mon réseau domestique via un NAS. Je suis à peu près le même message d'erreur. fatal: Référentiel a été mis à jour, mais impossible d'écrire new_index fichier. Vérifiez que le disque n'est pas plein ou quota n'est pas dépassé, et puis "git reset HEAD" pour récupérer. MacBook-Pro:le Temps perdu de compte de$ git reset HEAD erreur: impossible d'écrire le nouveau fichier d'index. fatale: impossible de réinitialiser le fichier d'index de révision de la "TÊTE". MacBook-Pro:le Temps perdu de compte de$ Pouvez-vous confirmer que c'est la même erreur? Et si oui, dois-je créer un tout nouveau référentiel?
    InformationsquelleAutor Rudi
  3. 3

    J'ai été à l'aide de Parallels Ubuntu sur mon Mac. Je pourrais git init, mais pas git add. Je crois que le problème est que la commande git add nécessite une synchronisation atomique de la sous-base de données de git. Et depuis le système de fichiers que j'utilisais était en fait sur mon Mac et Parallels a l'exportation à partir de mon Mac via un partage réseau. Je crois que cela signifie que git ne pouvais pas faire ce qu'il voulait. Déplacer les fichiers localement résolu le problème (Dans mon cas, cela a été facile, car j'ai été en utilisant DropBox sur mon Mac, je viens d'installer DropBox sur mon Ubuntu cours d'exécution Parallèles)

    • Je vais avoir le même problème sous VirtualBox et mon système de fichier n'est pas complet. C'est un peu frustrant que Dropbox est la réponse, mais je ne vois pas une meilleure solution.
    InformationsquelleAutor Scott Silver
  4. 2

    J'ai eu un similaires problème avec SFTP Lecteur Réseau (gratuit). La solution est la suivante: remplir chekcbox "Supprimer cible avant de passer" dans les Paramètres du Profil de SFTP Lecteur Réseau.

    InformationsquelleAutor Val Dubrava
  5. 2

    J'ai été en mesure de résoudre ce problème en allant dans le .git dans le dossier git lancé application et la suppression de l'index.verrouiller/fichier d'index. J'ai dû ré-indexer la totalité de l'app, mais il a résolu le problème.

    InformationsquelleAutor Travis Mathis
  6. 1

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

    InformationsquelleAutor Dave Halter
  7. 1

    Je tiens à souligner encore une cause de cette erreur

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

    Espère que ça vous aidera quelqu'un.

    InformationsquelleAutor Adonai
  8. 1

    J'ai eu le même problème. Je ne sais pas encore 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'indice de sudo chmod 777 index. Après cela, je suis en mesure de mettre en scène et de s'engager. Le problème est que j'ai pour ce faire, presque toutes les fois où j'ai quelque chose à la scène.

    InformationsquelleAutor Paulo Borralho Martins
  9. 1

    C'est vieux, mais la cause pour moi a été de Dropbox. Mon dépôt local était stocké dans mon dossier Dropbox, et j'ai dû interrompre la synchronisation Dropbox avant que je puisse terminer la commande.

    InformationsquelleAutor Omegastick
  10. 0

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

    • vous devez également mentionner les effets secondaires de git reset. vous perdrez tous les non validées/changements locaux.
    InformationsquelleAutor Renklauf
  11. 0

    D'ajouter: étonnamment, certains git plugins blocs du fichier d'index. Mon Eclipse Kepler a défaut du plug-in, que de temps en temps des mises à jour de ses propres informations à partir de repo git, le blocage de fichier d'index au cours de cette opération.

    InformationsquelleAutor kburtsev
  12. 0

    J'avais utilisé ce problème lors de l'utilisation de git sur visual studio, et ma solution a été d'exécuter visual studio en tant qu'administrateur

    InformationsquelleAutor No.8
  13. 0

    J'ai eu le même message d'erreur parce que Google Drive est la Sauvegarde et la Synchronisation client pour Windows n'avait pas sorti un verrou sur deux fichiers dans ce référentiel. Un travail autour de a été, après le client de synchronisation avait fini son travail: Process Explorer -> Find -> Trouver de poignée ou de DLL -> Fermer le Handle.

    InformationsquelleAutor JonB451
  14. 0

    J'ai eu le même problème. "fatal: Impossible d'écrire dans le nouveau fichier d'index"

    J'ai découvert que la raison en était que mon disque était plein. J'ai supprimé quelque chose d'autre, et puis mon repo git récupéré et tout a fonctionné à nouveau.

    InformationsquelleAutor Peter Lund