Отключить связь с файлом

Ответ 1

Обычно это означает, что процесс все еще использует этот конкретный файл (все еще имеет дескриптор)
(в Windows ProcessExplorer хорошо отслеживает подобные процессы)

Попробуйте закрыть другие программы и попробуйте еще раз git pull.

Обратите внимание, что у вас есть альтернатива с переменной GIT_ASK_YESNO.

Обновление января 2019 года:

Это должно быть еще более исправлено, с Git 2.21 (Q1 2019), так как "git gc" и "git repack" не закрывали открытые файлы пакета, которые они нашли ненужными перед удалением, которые не работали на неспособной платформе удаления открытого файла.
Это было исправлено.

См. commit 5bdece0 (15 декабря 2018 г.) от Йоханнеса Шинделина (dscho).
^{(Merged by Junio C Hamano -- [TG46] -- in commit 5104f8f, 18 Jan 2019)}

gc/repack: выпускать пакеты по мере необходимости

В Windows файлы не могут быть удалены или переименованы, если все еще есть дескрипторы, удерживаемые процессом.
Чтобы исправить это, мы ввели функцию close_all_packs().

Ранее мы позаботились о том, чтобы пакеты были выпущены непосредственно перед порождением git gc, на случай, если gc захочет удалить ненужные пакеты.

Но этот разработчик забыл, что самому gc также нужно отпустить пакеты, например, при объединении всех пакетов с помощью опции --aggressive.

Аналогично, git repack -d хочет удалить устаревшие пакеты и, следовательно, необходимо также закрыть все маркеры пакетов.

Обновление января 2016 года

Это должно быть исправлено в Git 2.8 (март 2016 г.) (см. Git 2.19, Q3 2018 ниже)

Смотрите коммит d562102, коммит dcacb1b, коммит df617b5, коммит 0898c96 (13 января 2016 г.) от Йоханнеса Шинделина (dscho).
^{(Merged by Junio C Hamano -- [TG416] -- in commit 3c80940, 26 Jan 2016)}

fetch: выпустить файлы пакета перед сборкой мусора

Перед автоматическим сбором файлов мы должны убедиться, что файлы пакетов выпущены на тот случай, если их нужно перепаковать и собрать мусор.

Многие кодовые пути, которые запускают "gc --auto" перед выходом, сохраняют сопоставленные файлы пакета и оставляют дескрипторы файлов открытыми, что не подходит для систем, которые не могут удалять открытые файлы.
Теперь они закрывают пакеты, прежде чем сделать это.

Это устраняет git-for-widows проблему 500.

Если посмотреть на тест , используемый для проверки этого нового подхода, возможный обходной путь (поскольку Git 2.8 еще не вышел) - это искусственное повышение gc.autoPackLimit.

git config gc.autoPackLimit 10000
git fetch
git config gc.autoPackLimit 50 # default value

git 2.8.4 (июнь 2016 г.) упоминает проблему 755, которая также должна решить проблему (commit 2db0641):

Убедитесь, что дескрипторы временных файлов не наследуются дочерними процессами

На самом деле, git-for-windows выпуск 500, упомянутый выше, действительно исправлен в Git 2.19, Q3 2018.
См. "Git - сбой отсоединения файла .idx и .pack (единственный дескриптор, принадлежащий этому файлу - git.exe)"

Ответ 2

Это ответ на конкретный Windows, поэтому я знаю, что это не относится к вам... Я просто включаю его в интересах будущих поисковиков.

В моем случае это произошло из-за того, что я запускал Git из невыполненной командной строки. "Запуск от имени администратора" исправил его для меня.

Ответ 3

Для меня это потому, что Visual Studio пыталась перезагрузить все измененные файлы из pull. Обновите визуальную студию, затем запустите git gc.

Ответ 4

В Windows с использованием GitHub для Windows я получил аналогичную ошибку в оболочке при запуске git gc:

Unlink of file '.git/objects/pack/pack-0b40ae7eae9b83edac62e19c07ff7b4c175244f6.idx' failed. Should I try again? (y/n)

Я решил это, закрыв GUI GitHub.

Ответ 5

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

Ответ 6

Закрыл Visual Studio и Rubymine и не получил ошибку снова. Один из них был виновником.

Ответ 7

Закройте свою среду IDE, затем выполните git pull. Это будет работать.

Ответ 8

У меня тоже есть эта проблема, но я узнал, что это был UltraEdit на этом пути, так как я использовал UE для организации и редактирования рабочей области eclipse ~~

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

После того, как я закрыл UltraEdit, проблема больше не повторялась.

Ответ 9

Это было вызвано в моем случае SimpLESS, компилятором LESS. Вы должны закрыть его в systray.

Ответ 10

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

Unlocker

Ответ 11

У меня это произошло в Windows XP, как с сообщением, застрявшим в цикле, так и с возможностью очистки путем ответа.

Зафиксированное вхождение было очищено закрытием Git -GUI. (Я запускал git merge -i в оболочке bash.)

Другие события произошли, возможно, из-за большого количества файлов в моем репозитории. Это произошло в основном с файлами .cod, которые я позже исключаю из контроля версий. (У меня есть причина для их отслеживания.) Я полагаю, что причина может быть связана со скоростью, с которой git использует дескрипторы файлов.

Интересно, связана ли проблема с способностью к очистке от ответа, связанная с Windows, поскольку два предыдущих плаката упомянули Windows, и никто не сказал, что у них есть проблема с другими операционными системами.

Ответ 12

У меня был PHPStorm открытый, закрытый, и все было хорошо.

Ответ 13

У меня была такая же проблема, и я закрыл все связанные программы из Window Task Manager. Однако он все еще не работал. Интересная часть состоит в том, что я запускал "Git rebase" вместо "Git pull", и это сработало!

Ответ 14

Ни один из приведенных выше ответов не работает для меня, но я запускаю команду git gc с параметром force, и это решает мою проблему.

'git gc --force'

[Windows 7, Запуск от имени администратора => Командная строка]

Ответ 15

Попробуйте запустить редактор командной строки в административном режиме и выполните команду. Это помогает и решает проблему. :)