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

Я видел много других веток об этом, и они не помогают.

У меня очень простое репо - два файла JavaScript. У меня на Macbook более 100 ГБ. Когда я пытаюсь переместить файлы в подкаталог и локально обрабатывать изменения, я получаю ...

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

Это происходит независимо от того, выполняю ли я все действия в терминале или использую графический интерфейс, например SourceTree. Кроме того, один из файлов блокируется, и я не могу удалить рабочий каталог, пока не выйду из системы и не вернусь обратно.

Почему это происходит? Блокировка препятствует постановке чего-либо? Если да, то что / как мне разблокировать проблемный файл на OS X ?? Удаленное репо - это Google Code, если это имеет значение, хотя я еще не нажимаю на удаленный. Все местное.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

rm -f ./.git/index.lock

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

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

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

Проверьте это ls -leв папке .git.

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

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

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

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

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

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

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

Это сообщение об ошибке fatal: Unable to write new index fileозначает , что мы не могли написать новое содержимое в файл индекс мерзавца .git\index(см здесь для получения дополнительной информации о индексе мерзавца). Изучив все ответы на этот вопрос, я резюмирую следующие основные причины:

• Размер нового содержимого превышает доступную емкость диска. ( Решение : очистите дисковое пространство)
• У пользователей нет прав доступа к этому файлу. ( Решение : дайте разрешение)
• У пользователей есть разрешение, но они .git\indexзаблокированы другими пользователями или процессами. ( Решение : разблокировать файл)

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

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

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

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

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

Скорее всего, это вызвано тем, что какое-то программное обеспечение блокирует индексный файл вашего репо, например программное обеспечение для резервного копирования, антивирусы, 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раз.

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

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

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

Контекст:

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>

и вы снова на правильном пути!

!! ВАЖНЫЙ !!

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

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

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

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

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

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

Я запускаю git log, чтобы проверить определенную фиксацию, затем я не вышел из нее должным образом, я нажимаю ctrl + c, чтобы выйти из нее.

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

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

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