Rails 3 / Git / Bundler Fatal не может разобрать объект

Question

При попытке установки комплекта я получаю следующую ошибку

Fatal could not parse object '8c11dd........
Git error: command git reset --hard '8c11dd

If this error persists you can try removing the cache directory.

Безуспешно удалили каталог кеша, кто-нибудь видел эту ошибку раньше?*

Answer 1

Произошла та же ошибка, когда я перемещал репозитории между серверами.Решил это, удалив Gemfile.lock и запустив bundle install.Это сгенерировало обновленный Gemfile.lock, который помог устранить ошибку.

Answer 2

Если вы используете Capistrano, удаление (shared /) кэшированной копии должно решить проблему.

Answer 3

Многие из постеров здесь верны в том смысле, что это, скорее всего, связано с тем, что Gemfile.lock не синхронизирован из-за перемещения или перемещения репозитория, но, как отмечали другие, удаление его не является мудрым решением.,Проверьте Gemfile.lock и найдите запись GIT для рассматриваемого репо.Важно проверить, на какой атрибут метаданных revision он указывает ... Скорее всего, он указывает на неверный хеш ревизии, который больше не существует.

Мой совет - вручную отредактировать его так, чтобы он указывал на ветку, которую вы хотите развернуть, путем перекрестной ссылки на него с реальным лог-файлом репо (так что вы должны убедиться, что он согласуется с тем, который на самом деле находится в вашем фактическом гемфайле)следующим образом:

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)

Answer 4

Что-то должно быть случилось с хранилищем. В моем случае это было удалено / перемещено. Поэтому я только что изменил git URL.

Если ваш :git => указывает на github, возможно, стоит посетить страницу проекта github.

Answer 5

У меня была такая же проблема с Capistrano при использовании set :deploy_via, :remote_cache, когда я переключился на другой github-репозиторий.

Мой рецепт capistrano указывал на новый форк, но кэш на удаленных серверах все еще имел origin, указывающий на старый репозиторий, и поэтому он не находил новые коммиты, которые я выдвинул на новый форк.

Исправлено выполнением на каждом из удаленных серверов:

git remote set-url origin <new fork>

Answer 6

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

Я нацеливаюсь на конкретную версию в Gemfile, но для целей разработки я изменил bundle config, чтобы получить локальную версию. Я установил другую версию на своей локальной машине, которая делает цель Gemfile.lock чем-то другим в specs.

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

Чтобы исправить это, просто укажите VERSION в вашем драгоценном камне в соответствии с тем, который вы разрабатываете / толкаете, и все должно быть в порядке.

gem "my-gem", git: "https://github.com/Loschcode/my-gem.git", branch: "master", tag: "v0.2.2"

Answer 7

Эта проблема возникает, когда произошли изменения, такие как принудительные изменения в git-репо, на который есть ссылка в Gemfile.

Решение состоит в том, чтобы прокомментировать строку gem в Gemfile, запустить bundle, раскомментировать ее иснова связать.Тогда Gemfile.lock будет ссылаться на действительную версию git.

Думаю, это тоже поможет: bundle update my_gem_name

Answer 8

Вы можете использовать флаг «--source» с «обновлением пакета». Так будет:

bundle update --source your_gem

Answer 9

В моем случае ветвь git, которую я использовал для гема, была объединена с master, а ветка удалена.Обновление моего Gemfile, удаление Gemfile.lock и повторный запуск bundle решили эту проблему для меня.