Ответ 1
Включить ту же ошибку, когда я переместил репозитории на серверы. Разрешил его, удалив Gemfile.lock и выполнив bundle install
. Это создало обновленный файл Gemfile.lock, который помог устранить ошибку.
При попытке установки пакета я получаю следующую ошибку:
Fatal could not parse object '8c11dd........
Git error: command git reset --hard '8c11dd
If this error persists you can try removing the cache directory.
Удалили кеш-каталог без успеха, кто-нибудь видел эту ошибку раньше?
Windows 7 64-бит
Включить ту же ошибку, когда я переместил репозитории на серверы. Разрешил его, удалив Gemfile.lock и выполнив bundle install
. Это создало обновленный файл Gemfile.lock, который помог устранить ошибку.
Если вы используете Capistrano, удаление (shared/) кешированной копии должно решить проблему.
Многие из плакатов здесь верны в том смысле, что они, скорее всего, связаны с тем, что Gemfile.lock не синхронизирован из-за перемещения или перемещения репозитория, но, как отмечали другие, удаление не является мудрым решением, Осмотрите Gemfile.lock и найдите запись GIT для рассматриваемого репо. Важно проверить, что атрибут метаданных revision
указывает на... Скорее всего, это указывает на плохой хеш хеста, который больше не существует.
Мой совет состоит в том, чтобы вручную отредактировать его, чтобы указать на ветку, которую вы хотите вытащить, перекрестно ссылаясь на нее с фактическим файлом журнала Repo (так что вы убедитесь, что он соответствует тому, который находится в вашем фактическом Gemfile) следующим образом:
GIT
remote: https://github.com/YourUserOrOrganization/your-gem-repo.git
revision: <UPDATE AND FIX ME!>
specs:
some-random-dep1 (2.4.3)
some-random-dep2 (>= 1.7.9)
some-random-dep3 (>= 1.6.7)
Что-то должно было произойти с репозиторием. В моем случае он был удален/перемещен. Поэтому я просто изменил URL git
.
Если ваш :git =>
указывает на github, может быть хорошей идеей посетить эту страницу проекта github.
У меня была та же проблема с Capistrano, использующей set :deploy_via, :remote_cache
, когда я переключился на другую виджет github репозитория.
Мой рецепт capistrano указывал на новую вилку, но кеш на удаленных серверах все еще имел origin
, указывающий на старый репозиторий, и поэтому он не обнаружил новые коммиты, которые я нажал на новую вилку.
Исправлено путем выполнения на каждом из удаленных серверов:
git remote set-url origin <new fork>
В моем случае ветвь git, которую я использовал для драгоценного камня, была объединена с мастером, а ветвь удалена. Обновление моего Gemfile
, удаление Gemfile.lock
и повторное выполнение bundle
решили для меня.
Вы можете использовать флаг '- source' с 'bundle update'. Так будет:
bundle update --source your_gem
Эта проблема возникает, когда произошли изменения, такие как принудительные нажатия на репо git, на которое ссылается в Gemfile.
Решение состоит в том, чтобы прокомментировать эту строку gem в Gemfile, запустить пакет, раскомментировать его и снова связать. Затем Gemfile.lock будет ссылаться на действительную версию git.
Думаю, это тоже поможет:
bundle update my_gem_name
В настоящее время я создаю драгоценный камень, и проблема немного отличалась от других.
Я нацелен на определенную версию в Gemfile
, но для целей развития я изменил bundle config
, чтобы получить локальную версию. Я устанавливаю другую версию на моем локальном компьютере, что делает Gemfile.lock
целью чего-то еще в specs
.
Этот файл отправляется через сервер через git, и сервер, очевидно, не может получить доступ к такой версии gem...
Чтобы исправить это, просто укажите VERSION
в своем камне в соответствии с тем, который вы разрабатываете/нажимаете, и все должно быть хорошо.
gem "my-gem", git: "https://github.com/Loschcode/my-gem.git", branch: "master", tag: "v0.2.2"