Git 'fatal: Не вдається записати новий індексний файл'

Я бачив багато інших тем про це, і вони не допомагають.

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

fatal: Неможливо записати новий індексний файл

Це трапляється, чи я виконую всі дії в терміналі, чи використовую графічний інтерфейс типу SourceTree. Крім того, один з файлів стає заблокованим, і я не можу видалити робочий каталог, поки не вийду з системи і не ввійду назад.

Чому це відбувається? Чи перешкоджає замок щось робити? Якщо так, то що / як розблокувати файл проблеми на OS X ?? Віддалене репо є кодом Google, якщо це має значення, хоча я ще не натискаю на віддалений. Все місцеве.

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

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

Можливі рішення

Отже, після багатого перегляду Google, я спробував таке:

• зміна. git permsions (та сама проблема)
• зміна дозволів .git / index (та сама проблема)
• git додавання всіх змін, які потрібно здійснити (той самий випуск)
• git rm-ing видалених файлів, оскільки вони надто довго повідомляли про ім’я файлу (та сама проблема)
• скидання git (м'який | Голова | Жорсткий) (та сама проблема)
• git clean (те саме питання)
• вимкнення захисника Windows (те саме питання)
• оновлення git (та сама проблема)
• різні клієнти git (я використовую gitbash) (та сама проблема)
• випивати 2 кави замість 1 (те саме питання)

tl: dr - брудний розчин

Єдине, що вдалося вирішити проблему, було скопіювати індексний файл, видалити оригінал та перейменувати копію.

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

У моєму випадку призупинення синхронізації папкових скриньок вирішило проблему

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

Якщо у вас є налаштування github в якійсь службі синхронізації в Інтернеті, наприклад, в Google Drive або папці, спробуйте відключити синхронізацію, оскільки служба синхронізації намагається прочитати / записати у файл, оскільки 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. Після перезапуску затемнення воно працює як завжди.

Якщо ви знаходитесь у вікні Windows, переконайтесь, що програма, яку ви використовуєте, будь то Source Tree або git-термінал, працює як адміністратор. Я отримував таке саме точне повідомлення про помилку. Ви можете або клацнути правою кнопкою миші на програмі, щоб запуститись як адміністратор, або змінити її властивості, щоб завжди працювати як адміністратор.

Не вистачає місця - це проблема. Почистіть і повторіть спробу

У мене була така ж проблема. Я перезапустив комп’ютер, і проблема була вирішена.

ви спробували "git add". . чи все це зміниться? (ви можете видалити непотрібні додані файли шляхом скидання HEIT)

Повідомлення про помилку fatal: Unable to write new index fileозначає, що ми не могли записати новий вміст у файл індексу git .git\index(див. Тут для отримання додаткової інформації про git index). Переглянувши всі відповіді на це питання, я підсумовую наступні першопричини:

• Розмір нового вмісту перевищує доступну ємність диска. ( Рішення : Очистіть місця на диску)
• Користувачі не мають права доступу до цього файлу. ( Рішення : Надати дозвіл)
• Користувачі мають дозвіл, але .git\indexйого заблокують інші користувачі чи процеси. ( Рішення : розблокувати файл)

Посилання Дізнайтеся, який процес блокує файл або папку в Windows, визначає наступний підхід для з'ясування процесу, який блокує певний файл:

Провідник процесу SysInternals - перейдіть до пошуку> Знайти обробку або DLL. У текстовому полі "Обробка або підстрочка DLL:" введіть шлях до файлу (наприклад, "C: \ path \ to \ file.txt") і натисніть "Пошук". Усі процеси, які мають відкриту ручку до цього файлу, повинні бути перелічені.

Використовуйте вищезазначений підхід, щоб знайти який процес заблокований, .git\indexа потім зупиніть виконуваний файл блокування. Це розблокує .git\index.

Наприклад, Search Explorer Explorer показує, що .git\indexзаблоковано vmware-vmx.exe. Призупинення роботи віртуальної машини VMWare Player (яка отримувала доступ до git repo через спільну папку) вирішила проблему.

ЯКЩО ВИ ОЦІНЮЄМО ЦЕ НАПРАВЛЕНО:

Це, швидше за все, спричинено тим, що програмне забезпечення блокує індексний файл вашого репо, наприклад програмне забезпечення для резервного копіювання, антивіруси, 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 повертає a HEAD detached at <commit-SHA>

3. Яку-небудь операцію я робив локально, у мене була ця помилка. Більш конкретно:

   • git checkout
   • git reset HEAD - твердий

Рішення

1. Просто видалений файл <work-dir>/.git/index.
2. A 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екземпляр, який спостерігав за змінами у файловій системі.