Запуск версии 1.9.4.msysgit.0 из git, я получаю упомянутые ошибки почти каждый раз, когда я запускаю git gc в командной строке или через git gui, когда он предлагает мне "сжимать свободные объекты" ":
Counting objects: 1110956, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (269562/269562), done.
Writing objects: 100% (1110956/1110956), done.
Total 1110956 (delta 636114), reused 1110956 (delta 636114)
Unlink of file '.git/objects/pack/pack-207f1feb5376880778637c ... 8371cea62.pack'
failed. Should I try again? (y/n) n
Checking connectivity: 1110956, done.
Единственное решение, похоже, нажимает n для каждого из заблокированных файлов - как предложено этот поток:
Короткий ответ: нажмите 'n', чтобы пройти через все эти, а затем вручную запустить "git gc".
Поток также предполагает, что...
Проблема в том, что файлы хранятся открытым родительским git.exe того, который пытается выполнить gc.
... который, глядя на дерево процессов, вполне правдоподобен:
Мой вопрос: есть ли что-то, что я могу сделать, чтобы это предотвратить? Это становится очень раздражающим, когда приходится делать это несколько раз в день... И почему это происходит? Является ли это ошибкой git/w32-only?
Обновить 1: Чтобы уточнить - после нажатия n несколько раз, как описано, git gc завершается, а локальный репозиторий "чист", т.е. перезапуск git gc не вызывает проблемы с блокировкой файлов - но это только на некоторое время. После некоторого рабочего времени на repo – иногда через несколько минут, иногда по часам - ndash; репозиторий снова "грязный", и описанные проблемы преобладают. Выполнение git gc из git-bash вместо cmd, предложенное jsexpert, не помогает. Он также предположил, что другое программное обеспечение не git может содержать блокировки, о которых идет речь. Я скептически отношусь к этому, не в последнюю очередь из-за комментария в теме, связанной выше – Я думаю, что родительский процесс git содержит блокировки – но я все еще должен подтвердить это требование.
Обновление 2: Оказывается, что jsexpert был прав все время - по крайней мере, в моем случае это была действительно блокировка IDE на эти файлы... Итак, это проблема EGit Team Provider для Eclipse, а не git.
Обновление 3: Чтобы найти заблокированные файлы, вы можете, например, использовать один из этих бесплатных инструментов:
В обоих случаях используйте CTRL F, чтобы открыть диалог "Найти дескриптор".
Я рекомендую вам использовать git из git-bash (т.е. %GIT_HOME%\bin\bash.exe), а не из cmd.
После перехода на git-bash вы не должны ожидать этой проблемы, так как cmd - это команда Windows, которая может блокировать ваши файлы, а git-bash похожа на эмулятор UNIX, который не будет блокировать ваши файлы (даже если он действительно смотрит на ваши папки Windows).