Подтвердить что ты не робот

Rails 3/Git/Bundler Fatal не смог проанализировать объект

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

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-бит

4b9b3361

Ответ 1

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

Ответ 2

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

Ответ 3

Многие из плакатов здесь верны в том смысле, что они, скорее всего, связаны с тем, что 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)

Ответ 4

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

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

Ответ 5

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

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

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

git remote set-url origin <new fork>

Ответ 6

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

Ответ 7

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

bundle update --source your_gem

Ответ 8

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

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

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

Ответ 9

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

Я нацелен на определенную версию в 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"