Git 'fatal: Neue Indexdatei kann nicht geschrieben werden'

Ich habe viele andere Threads darüber gesehen und sie helfen nicht.

Ich habe ein sehr einfaches Repo - zwei JavaScript-Dateien. Ich habe mehr als 100 GB auf einem Macbook. Wenn ich versuche, die Dateien in ein Unterverzeichnis zu verschieben und die Änderungen, die ich erhalte, lokal durchzuführen ...

fatal: Neue Indexdatei kann nicht geschrieben werden

Dies geschieht unabhängig davon, ob ich alle Aktionen im Terminal ausführe oder ob ich eine GUI wie SourceTree verwende. Außerdem wird eine der Dateien gesperrt und ich kann das Arbeitsverzeichnis erst löschen, wenn ich mich abmelde und wieder anmelde.

Warum passiert dies? Verhindert das Schloss die Inszenierung von etwas? Wenn ja, was / wie entsperre ich die Problemdatei unter OS X? Das Remote-Repo ist Google Code, wenn das einen Unterschied macht, obwohl ich noch nicht auf die Remote drücke. Alles ist lokal.

In meinem Fall hatte die Festplatte nicht mehr genügend Speicherplatz, sodass ich Dateien von der Festplatte löschen musste, um Speicherplatz zu schaffen.

Ich habe das gleiche Problem in den letzten Tagen. Ohne mein Wissen war das gesamte Repo in ein neues Dateisystem verschoben worden. Als ich versuchte, den Git-Status auszuführen, wurde plötzlich gemeldet, dass jede Datei im Repo udpiert worden war.

Mögliche Lösungen

Nach langem Durchsuchen von Google habe ich Folgendes versucht:

• Ändern von .git-Berechtigungen (gleiches Problem)
• Ändern der Git / Index-Berechtigungen (gleiches Problem)
• Git Hinzufügen aller zu festschreibenden Änderungen (gleiches Problem)
• git rm-ing gelöschte Dateien, da sie Dateinamen zu lange Fehler meldeten (gleiches Problem)
• Git Reset (weich | Kopf | hart) (gleiches Problem)
• git clean (gleiches Problem)
• Windows Defender ausschalten (gleiches Problem)
• git aktualisieren (gleiches Problem)
• verschiedene Git-Clients (ich benutze Gitbash) (gleiches Problem)
• 2 statt 1 Kaffee trinken (gleiche Ausgabe)

tl: dr - schmutzige Lösung

Das einzige Problem, das behoben werden konnte, war das Kopieren der Indexdatei, das Löschen des Originals und das Umbenennen der Kopie.

Ich weiß, dass es nicht wirklich eine 'Lösung' ist, aber jetzt funktioniert es magisch> <, wobei alle Dateien / Zweige intakt sind. Wenn jemand weiß, warum dies funktionieren könnte, sagen Sie es.

In meinem Fall wurde das Problem durch Anhalten der Dropbox-Synchronisierung behoben

Ich hatte das gleiche Problem auf einem Mac. Es scheint durch Dateisystem-ACLs verursacht zu werden. Versuchen Sie chmod -RN /path/to/repo, die ACLs zu löschen. Danach konnte ich Änderungen vornehmen. Löschen Sie mit dem Trick zum Kopieren der Indexdatei das Original und verschieben Sie die Kopie zurück, um das gleiche Ergebnis zu erzielen.

Wenn Sie Ihr Github-Setup in einem Online-Synchronisierungsdienst wie Google Drive oder Dropbox eingerichtet haben, deaktivieren Sie die Synchronisierung, da der Synchronisierungsdienst versucht, in die Datei zu lesen / schreiben, während Github versucht, dasselbe zu tun, was dazu führt, dass Github nicht funktioniert korrekt.

Mir ist passiert, dass die Datei .git / index von einem anderen Prozess (meinem lokalen Entwicklungswebserver) verwendet wurde. Ich habe den Prozess beendet und dann hat es funktioniert.

Das Schließen von Visual Studio Code (in meinem Fall wird ein Hintergrundjob für den automatischen Uploader ausgeführt, der beim Speichern von Dateien ausgeführt wird) hat das Problem für mich behoben.

Dank für die Lösung: mein Freund und Kollege Arnel.

Das hat bei mir funktioniert:

rm -f ./.git/index.lock

In meinem Fall fügte die Lösung nur dem neuen Benutzer die Berechtigung hinzu.

Als ich ein neues Betriebssystem installiert habe, meine Repos verschoben habe und genau dieser Fehler angezeigt wurde, habe ich den Stammordner ausgewählt und dann den authentifizierten Benutzer hinzugefügt, um alle zu überprüfen

Ich hatte ACL (irgendwie) an alle Dateien im .git-Ordner angehängt.

Überprüfen Sie es mit ls -leim Ordner .git.

Sie können die ACL mit entfernen chmod -N (für einen Ordner / eine Datei) oder chmod -RN(rekursiv)

Ich denke, einige Hintergrundsicherungslösungen wie Google Backup und Sync blockieren den Zugriff auf die Indexdatei. Ich schloss die Anwendung und Sourcetree hatte überhaupt keine Probleme. Scheint, dass Dropbox dasselbe tut (@tonymayoral).

In meinem Fall war es ein gleichzeitig laufendes EGit. Nach dem Neustart von Eclipse funktioniert es wie gewohnt.

Wenn Sie sich in einer Windows-Box befinden, stellen Sie sicher, dass das von Ihnen verwendete Programm, unabhängig davon, ob es sich um den Quellbaum oder ein Git-Terminal handelt, als Administrator ausgeführt wird. Ich habe genau die gleiche Fehlermeldung erhalten. Sie können entweder mit der rechten Maustaste auf das Programm klicken, um es als Administrator auszuführen, oder seine Eigenschaften so ändern, dass es immer als Administrator ausgeführt wird.

Nicht genügend Speicherplatz ist ein Problem. Aufräumen und erneut versuchen

Ich hatte das gleiche Problem. Ich habe meinen Computer neu gestartet und das Problem wurde behoben.

Hast du 'git add' versucht? . wird es alle Änderungen? (Sie können unnötig hinzugefügte Dateien entfernen, indem Sie HEAD HEIT zurücksetzen.)

Die Fehlermeldung fatal: Unable to write new index filebedeutet , dass wir nicht den neuen Inhalt in der git Indexdatei schreiben konnten .git\index(siehe hier für weitere Informationen über git Index). Nachdem ich alle Antworten auf diese Frage überprüft habe, fasse ich die folgenden Ursachen zusammen:

• Die Größe des neuen Inhalts überschreitet die verfügbare Festplattenkapazität. ( Lösung : Reinigen Sie die Speicherplätze)
• Benutzer haben kein Zugriffsrecht auf diese Datei. ( Lösung : Erteilen Sie die Erlaubnis)
• Benutzer haben die Berechtigung, sind jedoch .git\indexvon anderen Benutzern oder Prozessen gesperrt. ( Lösung : Entsperren Sie die Datei)

Der Link Herausfinden, welcher Prozess eine Datei oder einen Ordner in Windows sperrt, gibt den folgenden Ansatz an, um den Prozess herauszufinden, der eine bestimmte Datei sperrt:

SysInternals Process Explorer - Gehen Sie zu Suchen> Handle oder DLL suchen. Geben Sie im Textfeld "Handle oder DLL-Teilzeichenfolge:" den Pfad zur Datei ein (z. B. "C: \ Pfad \ zu \ Datei.txt") und klicken Sie auf "Suchen". Alle Prozesse, die ein offenes Handle für diese Datei haben, sollten aufgelistet werden.

Verwenden Sie den obigen Ansatz, um herauszufinden, welcher Prozess gesperrt ist, .git\indexund stoppen Sie dann die ausführbare Sperrdatei. Dies wird freigeschaltet .git\index.

Beispielsweise zeigt die Prozess-Explorer-Suche , dass .git\indexdurch gesperrt ist vmware-vmx.exe. Das Anhalten der virtuellen VMWare Player-Maschine (die über einen freigegebenen Ordner auf das Git-Repo zugegriffen hat) hat das Problem behoben.

WENN SIE DIES WÄHREND EINER REBASE ERHALTEN:

Dies wird höchstwahrscheinlich durch eine Software verursacht, die die Indexdatei Ihres Repos sperrt, z. B. Sicherungssoftware, Antivirenprogramme, IDEs oder andere Git-Clients.

In den meisten Fällen ist die Sperre nur für einen kurzen Moment und geschieht daher nur aus Zeitgründen und aus Pech.

Allerdings git rebase --continuewird sich beschweren über die nächste Befehl ist ein leerer begehen:

The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

    git commit --allow-empty

Um dies zu beheben, führen Sie es einfach aus git resetund versuchen Sie es git rebase --continueerneut.

Problem: Beim Auschecken einiger geänderter Dateien in Git ist dieser Fehler aufgetreten. Ich hatte zwei Benutzer ABC und XYZ. Dateien haben uid: gid von ABC, aber es hat keinen Git-Zugriff und versucht, die Dateien mit demselben auszuchecken.

Die Lösung, die ich versucht habe: XYZ hat Git-Zugriff, hat versucht, Dateien mit sudo auszuchecken und es hat funktioniert .. !!

Folgendes hat bei mir funktioniert:

Kontext:

1. Erstellen eines Projekts auf einem Server

2. git status gibt a zurück HEAD detached at <commit-SHA>

3. Was auch immer ich vor Ort operierte, ich hatte diesen Fehler. Genauer:

   • Git Checkout
   • Git Reset HEAD --hard

Lösung

1. Einfach entfernte Datei <work-dir>/.git/index.
2. A git statuswürde anzeigen, dass nicht alle Dateien im Projekt verfolgt werden (keine Überraschung hier).
3. git reset HEAD --hard
4. Zurück zu HEAD detached at <commit-SHA>wenn du ein machst git status, aber dann solltest du dazu in der Lage sein
5. git checkout <some-branch>

und du bist wieder auf dem richtigen Weg!

!! WICHTIG !!

Dies funktioniert nur, weil ich "nur" baue. Am Code wurden keine wertvollen Änderungen vorgenommen. Wenn Sie sich tatsächlich in der "Entwicklungszeit" befinden, würde ich empfehlen, zuerst Ihre Arbeit zu speichern oder eine andere Methode zu wählen.

Hoffe es wird helfen :).

Ich hatte dieses Problem mit GitExtensions unter Windows. Behoben durch Erteilen der vollständigen Berechtigung für den aktuellen Benutzer (mich) für den Ordner, der das Repo enthielt.

Ein anderes Mal konnte ich, obwohl ich den Fehler von Git Extensions erhielt, dieselben Dateien aus Visual Studio 2015 festschreiben.

Ein anderes Mal musste ich die "Index" -Datei aus dem .git-Ordner löschen

Mein Fall ist ein bisschen interessant:

Ich führe das Git-Protokoll aus, um ein bestimmtes Commit zu überprüfen. Dann habe ich es nicht richtig beendet. Ich drücke Strg + C, um es zu beenden.

Dann scheint der Index gesperrt zu sein. Also führe ich git log erneut aus und drücke dann Q, um es zu beenden.

Problem gelöst. :) :)

In meinem Fall war es eine nodemonInstanz, die das Dateisystem auf Änderungen überwacht.