Git 'fatal: невозможно записать новый индексный файл'

Ответ 1

В моем случае на диске закончилось свободное место, поэтому мне пришлось удалить файлы с жесткого диска, чтобы освободить место.

Ответ 2

У меня была эта же проблема за последние несколько дней. В принципе, без моего ведома, все репо было перемещено в новую файловую систему, когда я пытался запустить статус git, внезапно сообщалось, что каждый файл в репо был обнулен.

Возможные решения

Итак, после многократной очистки Google я пробовал следующее:

• изменение .git permssions (одна и та же проблема)
• изменение разрешений .git/index (одна и та же проблема)
• git добавление всех изменений в commit (та же проблема)
• git rm-ing удаленные файлы, так как они сообщали о слишком длинных ошибках файла (такая же проблема)
• git reset (soft | Head | Hard) (та же проблема)
• git clean (такая же проблема)
• отключить защитник Windows (та же проблема)
• обновление git (та же проблема)
• разные клиенты git (я использую gitbash) (та же проблема)
• пить 2 кофе вместо 1 (одна и та же проблема)

tl: dr - грязное решение

Единственное, что удалось решить проблему, это скопировать индексный файл, удалить оригинал и переименовать копию.

Я знаю, что это не "решение", а теперь его магически работающий > <, со всеми файлами/ветвями. Если кто-нибудь знает, почему это может иметь работу, расскажите.

Ответ 3

У меня была такая же проблема на Mac. Кажется, это вызвано ACL файловой системы. Попробуйте chmod -RN /path/to/repo очистить списки управления доступом. Сделав это, я смог внести изменения. Используя трюк для копирования индексного файла, удалите оригинал и переместите копию назад, получив тот же результат.

Ответ 4

Если у вас настроен github в какой-либо онлайн-службе синхронизации, например, на google drive или dropbox, попробуйте отключить синхронизацию, поскольку служба синхронизации пытается прочитать/записать файл, как github пытается сделать то же самое, что приводит к неработоспособности github. правильно.

Ответ 5

В моем случае приостановка синхронизации Dropbox решила проблему

Ответ 6

Случилось со мной, что файл .git/index использовался другим процессом (мой локальный веб-сервер разработки). Я закрыл процесс, а затем он работал.

Ответ 7

Это сработало для меня:

rm -f ./.git/index.lock

Ответ 8

В моем случае решением было только добавление разрешения новому пользователю.

Когда я установил новую ОС, переместил свои репозитории, и это показывало именно эту ошибку, я выбрал корневую папку, а затем добавил аутентифицированного пользователя, чтобы проверить все

Ответ 9

У меня был ACL (каким-то образом), прикрепленный ко всем файлам в папке .git.

Проверьте его с помощью ls -le в папке .git.

Вы можете удалить ACL с помощью chmod -N (для папки/файла) или chmod -RN (рекурсивный)

Ответ 10

Я думаю, что некоторые фоновые решения для резервного копирования, такие как Google Backup и Sync, блокируют доступ к файлу индекса. Я закрыл приложение, и у Sourcetree не было никаких проблем. Кажется, что Dropbox делает то же самое (@tonymayoral).

Ответ 11

В моем случае это был одновременный запуск EGit. После перезапуска eclipse он работает как обычно.

Ответ 12

Если вы находитесь в окне Windows, убедитесь, что используемая вами программа, будь то исходное дерево или терминал git, работает как администратор. Я получал то же точное сообщение об ошибке. Вы можете щелкнуть правой кнопкой мыши по программе, чтобы ее можно было запустить как администратор или изменить ее свойства, чтобы она всегда запускалась как администратор.

Ответ 13

Закрытие кода Visual Studio (в моем случае есть фоновая работа автозагрузки, выполняемая при сохранении файла), решила проблему для меня.

Кредит на решение: мой друг и коллега Арнел.

Ответ 14

Вы попробовали 'git add.', будут ли все изменения? (вы можете удалить ненужные добавленные файлы с помощью git reset HEAD)

Ответ 15

Недостаток места - это проблема. Очистите и попробуйте снова

Ответ 16

Эта проблема может быть вызвана тем, что .git\index заблокирован процессом.

Ссылка Узнайте, какой процесс блокирует файл или папку в Windows определяет следующий подход для поиска заблокированного файла:

SysInternals Process Explorer - выберите "Найти" > "Найти дескриптор" или "DLL". В текстовом поле "Ручка или DLL подстрока:" введите путь к файлу (например, "C:\path\to\file.txt" ) и нажмите "Поиск". Все процессы, у которых есть открытый дескриптор этого файла, должны быть перечислены.

Используйте описанный выше подход, чтобы определить, какой процесс заблокирован .git\index, а затем остановить исполняемый файл блокировки. Это должно решить проблему.

Например, Process Explorer Search показывает, что мой .git\index был заблокирован vmware-vmx.exe. Приостановка виртуальной машины проигрывателя VMWare (доступ к репо через git через общую папку) решила проблему.

Ответ 17

У меня такая же проблема. Я перезагрузил компьютер, и проблема была решена.

Ответ 18

ЕСЛИ ВЫ ПОЛУЧАЕТЕ ЭТО ВО ВРЕМЯ РЕБЕССА:

Это, скорее всего, вызвано тем, что какое-то программное обеспечение блокирует индексный файл вашего репо, например, программное обеспечение для резервного копирования, антивирусы, IDE или другие клиенты git.

В большинстве случаев блокировка выполняется только на короткое мгновение, и поэтому это просто происходит из-за неудачного времени и неудачи.

Однако git rebase --continue будет жаловаться на следующую команду, являющуюся пустой фиксацией:

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

    git commit --allow-empty

Чтобы исправить это, просто запустите git reset и снова попробуйте git rebase --continue.

Ответ 19

Проблема: когда я проверял некоторые измененные файлы в git, я получил эту ошибку. У меня было два пользователя ABC и XYZ. У файлов есть uid: gid из ABC, но у него нет доступа к git, и они пытаются извлечь файлы с тем же именем.

Решение, которое я попробовал: XYZ имеет доступ к git, попытался проверить файлы с помощью sudo, и это сработало.. !!

Ответ 20

Вот что сработало для меня:

Контекст:

1. Сборка проекта на сервере

2. git status возвращает HEAD detached at <commit-SHA>

3. Какую бы операцию я ни делал локально, у меня была эта ошибка. Более конкретно:

   • Git Checkout
   • git reset HEAD --hard

Решение

1. Просто удалил файл <work-dir>/.git/index.
2. Состояние git status будет означать, что все файлы в проекте не отслеживаются (здесь нет ничего удивительного).
3. git reset HEAD --hard
4. Назад к HEAD detached at <commit-SHA> при выполнении состояния git status, но тогда вы сможете
5. git checkout <some-branch>

и ты вернулся на трассу!

!! ВАЖНЫЙ !!

Это работает только потому, что я "веселый" строй. Никаких драгоценных изменений не было выполнено в коде. Если вы на самом деле находитесь в "время разработки", то я бы рекомендовал сначала сохранить вашу работу или перейти на другой метод.

Надеюсь, это поможет :).

Ответ 21

У меня была эта проблема с использованием GitExtensions на Windows. Исправлено путем предоставления полного разрешения для текущего пользователя (меня) на папку, содержащую репо.

В другой раз, несмотря на то, что я получал ошибку от Git Extensions, я смог зафиксировать те же файлы из Visual Studio 2015.

В другой раз мне пришлось удалить файл "index" из папки .git

Ответ 22

Мой случай немного интересен:

Я запускаю git log для проверки определенного коммита, затем я не вышел из него должным образом, я нажимаю Ctrl + C, чтобы выйти из него.

Тогда индекс, кажется, был заблокирован. Поэтому я снова запускаю git log, затем нажимаю Q, чтобы выйти из него.

Проблема исправлена. :)