Git „fatal: nie można zapisać nowego pliku indeksu”

Widziałem wiele innych wątków na ten temat i one nie pomagają.

Mam bardzo proste repozytorium - dwa pliki JavaScript. Mam ponad 100 GB na Macbooku. Kiedy próbuję przenieść pliki do podkatalogu i lokalnie przygotować zmiany, które otrzymuję ...

krytyczny: nie można zapisać nowego pliku indeksu

Dzieje się tak, niezależnie od tego, czy wykonuję wszystkie czynności w terminalu, czy używam GUI, takiego jak SourceTree. Ponadto jeden z plików zostaje zablokowany i nie mogę usunąć katalogu roboczego, dopóki się nie wyloguję i nie zaloguję.

Dlaczego to się dzieje? Czy blokada zapobiega przemieszczaniu się czegoś? Jeśli tak, co / jak mogę odblokować plik powodujący problem w systemie OS X? Zdalne repozytorium to Google Code, jeśli to robi różnicę, chociaż jeszcze nie pcham na pilota. Wszystko jest lokalne.

W moim przypadku na dysku zabrakło miejsca, więc musiałem usunąć pliki z dysku twardego, aby zrobić miejsce.

Od kilku dni mam ten sam problem. Zasadniczo bez mojej wiedzy całe repozytorium zostało przeniesione do nowego systemu plików, kiedy próbowałem uruchomić status git, nagle zgłaszał, że każdy plik w repozytorium został zaktualizowany.

Możliwe rozwiązania

Tak więc po wielu przeszukiwaniu google próbowałem następujących rzeczy:

• zmiana uprawnień .git (ten sam problem)
• zmiana uprawnień .git / index (ten sam problem)
• git dodający wszystkie zmiany do zatwierdzenia (ten sam problem)
• git rm-rowanie usuniętych plików, ponieważ zgłaszały zbyt długie błędy nazwy pliku (ten sam problem)
• reset git (soft | Head | Hard) (ten sam problem)
• git clean (ten sam problem)
• wyłączanie Windows Defender (ten sam problem)
• aktualizacja git (ten sam problem)
• różni klienci git (używam gitbash) (ten sam problem)
• wypicie 2 kaw zamiast 1 (ten sam problem)

tl: dr - brudne rozwiązanie

Jedyne, co udało się rozwiązać, to skopiowanie pliku indeksu, usunięcie oryginału i zmiana nazwy kopii.

Wiem, że to naprawdę nie jest „rozwiązanie”, ale teraz działa magicznie> <, z nienaruszonymi wszystkimi plikami / gałęziami. Jeśli ktoś wie, dlaczego to może zadziałać, powiedz.

W moim przypadku wstrzymanie synchronizacji skrzynki referencyjnej rozwiązało problem

Miałem ten sam problem na komputerze Mac. Wydaje się, że jest to spowodowane listami ACL systemu plików. Spróbuj chmod -RN /path/to/repowyczyścić listy ACL. Po wykonaniu tej czynności byłem w stanie wprowadzić zmiany. Używając sztuczki, aby skopiować plik indeksu, usuń oryginał i przenieś kopię z powrotem, osiągając ten sam rezultat.

Jeśli masz konfigurację github w jakiejś usłudze synchronizacji online, takiej jak dysk Google lub Dropbox, spróbuj wyłączyć synchronizację, ponieważ usługa synchronizacji próbuje odczytać / zapisać w pliku, ponieważ github próbuje zrobić to samo, co prowadzi do tego, że github nie działa prawidłowo.

Zdarzyło mi się, że plik .git / index był używany przez inny proces (mój lokalny serwer WWW). Zakończyłem proces i zadziałało.

Zamknięcie programu Visual Studio Code (który w moim przypadku ma w tle zadanie automatycznego przesyłania działające przy zapisywaniu pliku) rozwiązało problem.

Kredyt za rozwiązanie: mój przyjaciel i kolega Arnel.

To zadziałało dla mnie:

rm -f ./.git/index.lock

W moim przypadku rozwiązaniem było tylko dodanie uprawnień nowemu użytkownikowi.

Kiedy zainstalowałem nowy system operacyjny, przeniosłem moje repozytoria i pokazywał dokładnie ten błąd Wybrałem folder główny, a następnie dodałem uwierzytelnionego użytkownika, aby sprawdzić wszystko

Miałem ACL (w jakiś sposób) dołączoną do wszystkich plików w folderze .git.

Sprawdź to ls -lew folderze .git.

Listę ACL można usunąć za pomocą chmod -N(dla folderu / pliku) lub chmod -RN(cyklicznie)

Myślę, że niektóre rozwiązania do tworzenia kopii zapasowych w tle, takie jak Kopia zapasowa i synchronizacja Google, blokują dostęp do pliku indeksu. Zamknąłem aplikację i Sourcetree nie miało żadnych problemów. Wygląda na to, że Dropbox robi to samo (@tonymayoral).

W moim przypadku był to jednocześnie działający EGit. Po ponownym uruchomieniu eclipse działa jak zwykle.

Jeśli korzystasz z komputera z systemem Windows, upewnij się, że program, którego używasz, niezależnie od tego, czy jest to drzewo źródłowe, czy terminal git, działa jako administrator. Otrzymałem dokładnie ten sam komunikat o błędzie. Możesz kliknąć program prawym przyciskiem myszy, aby uruchomić go jako administrator, lub zmienić jego właściwości, aby zawsze działał jako administrator.

Brak wystarczającej ilości miejsca jest problemem. Oczyść i spróbuj ponownie

Miałem ten sam problem. Uruchomiłem ponownie komputer i problem został rozwiązany.

czy próbowałeś „git add”. . czy to wszystkie zmiany? (możesz usunąć niepotrzebne dodane pliki przez git reset HEAD)

Komunikat o błędzie fatal: Unable to write new index fileoznacza, że ​​nie mogliśmy zapisać nowej treści do pliku indeksu git .git\index(zobacz tutaj, aby uzyskać więcej informacji o indeksie git). Po przejrzeniu wszystkich odpowiedzi na to pytanie podsumowuję następujące przyczyny:

• Rozmiar nowej zawartości przekracza dostępną pojemność dysku. ( Rozwiązanie : wyczyść miejsca na dysku)
• Użytkownicy nie mają prawa dostępu do tego pliku. ( Rozwiązanie : udziel pozwolenia)
• Użytkownicy mają uprawnienia, ale .git\indexsą zablokowani przez innych użytkowników lub procesy. ( Rozwiązanie : odblokuj plik)

Łącze Dowiedz się, który proces blokuje plik lub folder w systemie Windows, określa następujące podejście, aby dowiedzieć się, jaki proces blokuje określony plik:

SysInternals Process Explorer - przejdź do Find> Find Handle or DLL. W polu tekstowym „Uchwyt lub podciąg DLL:” wpisz ścieżkę do pliku (np. „C: \ ścieżka \ do \ plik.txt”) i kliknij przycisk „Wyszukaj”. Powinny być wymienione wszystkie procesy, które mają otwarte dojście do tego pliku.

Użyj powyższego podejścia, aby znaleźć zablokowany proces, .git\indexa następnie zatrzymaj plik wykonywalny blokujący. To się odblokuje .git\index.

Na przykład Wyszukiwanie w Process Explorer pokazuje, że .git\indexjest zablokowane przez vmware-vmx.exe. Zawieszenie maszyny wirtualnej VMWare Player (która uzyskiwała dostęp do repozytorium git przez udostępniony folder) rozwiązało problem.

JEŚLI OTRZYMASZ TO PODCZAS ODBUDOWY:

Najprawdopodobniej jest to spowodowane przez oprogramowanie blokujące plik indeksu repozytorium, takie jak oprogramowanie do tworzenia kopii zapasowych, antywirusy, IDE lub inni klienci git.

W większości przypadków blokada jest tylko na krótką chwilę, więc dzieje się tak z powodu złego czasu i pecha.

Jednak git rebase --continuebędzie narzekać, że następne polecenie jest pustym zatwierdzeniem:

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

    git commit --allow-empty

Aby to naprawić, po prostu uruchom git reseti spróbuj git rebase --continueponownie.

Problem: podczas sprawdzania niektórych zmodyfikowanych plików w git otrzymałem ten błąd. Miałem dwóch użytkowników ABC i XYZ. pliki mają uid: gid ABC, ale nie mają dostępu git i próbują wyewidencjonować pliki tym samym.

Rozwiązanie, które wypróbowałem: XYZ ma dostęp git, próbował sprawdzić pliki za pomocą sudo i zadziałało .. !!

Oto, co zadziałało dla mnie:

Kontekst:

1. Budowanie projektu na serwerze

2. git status zwraca a HEAD detached at <commit-SHA>

3. Cokolwiek wykonałem lokalnie, miałem ten błąd. Dokładniej:

   • git checkout
   • git reset HEAD --hard

Rozwiązanie

1. Po prostu usunięty plik <work-dir>/.git/index.
2. A git statusoznaczałoby, że wszystkie pliki w projekcie nie są śledzone (nic dziwnego).
3. git reset HEAD --hard
4. Wracając do HEAD detached at <commit-SHA>robienia git status, ale wtedy powinieneś być w stanie
5. git checkout <some-branch>

i wracasz na właściwe tory!

!! WAŻNE !!

Działa to tylko dlatego, że buduję „merly”. W kodzie nie dokonano żadnych cennych modyfikacji. Jeśli faktycznie znajdujesz się w „czasie tworzenia”, radziłbym najpierw zapisać swoją pracę lub wybrać inną metodę.

Mam nadzieję, że to pomoże :).

Miałem ten problem podczas korzystania z GitExtensions w systemie Windows. Naprawiono przez udzielenie pełnych uprawnień aktualnemu użytkownikowi (mnie) do folderu zawierającego repozytorium.

Innym razem, mimo że otrzymywałem błąd z Git Extensions, udało mi się zatwierdzić te same pliki z Visual Studio 2015.

Innym razem musiałem usunąć plik „index” z folderu .git

Mój przypadek jest trochę interesujący:

Uruchamiam dziennik git, aby sprawdzić określone zatwierdzenie, ale nie wyszedłem z niego poprawnie, wciskam ctrl + c, aby go zamknąć.

Wtedy wydaje się, że indeks został zablokowany. Więc ponownie uruchamiam git log, a następnie naciskam Q, aby go zamknąć.

Problem rozwiązany. :)

W moim przypadku była to nodemoninstancja obserwująca zmiany w systemie plików.