2012-01-05 17 views
24

Cuando se intenta instalar paquete que recibo el siguiente errorRails 3/Git/Bündler Fatal No se pudo analizar el objeto

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

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

ha quitado el directorio de caché sin éxito, alguien ha visto este error antes?

Windows 7 de 64 bits

+0

¿Es esa comilla simple un error? Eso ciertamente causaría un problema. – d11wtq

+0

Para aclarar, algo en ellos Gemfile apunta a un git ref 8c11dd, pero hay una cita única espuria allí. – d11wtq

+0

Lo siento chicos, para aclarar que debe ser '8c11dd ........' Es un hash largo seguido de una cotización de cierre –

Respuesta

5

Algo debe haber ocurrido en el repositorio. En mi caso, fue eliminado/movido. Así que acabo de cambiar la url git.

Si su :git => apunta hacia github, podría ser una buena idea visitar la página del proyecto github.

31

Se produjo el mismo error cuando moví repositorios a través de servidores. Se resolvió eliminando Gemfile.lock y ejecutando bundle install. Esto generó un Gemfile.lock actualizado que ayudó a resolver el error.

+1

Gracias por esto. Estaba teniendo el mismo problema y estaba intentando un montón de cosas diferentes, pero olvídate de esta simple. Lo tengo trabajando. – Fralcon

+4

Eliminar Gemfile.lock suele ser una mala idea. Cuando ejecutas 'bundle install' nuevamente obtendrás las últimas versiones de gemas no especificadas. Lo cual muy probablemente cause algunos dolores de cabeza. –

+1

De acuerdo con Tony. Cuando encontré este error, no fue un problema ejecutar 'bundle install' en mi proyecto. Una mejor alternativa será usar 'bundle update '. – user553620

1

Tuve el mismo problema con Capistrano al usar set :deploy_via, :remote_cache cuando cambié a una nueva bifurcación de depósito de github.

La receta de Mi capistrano apuntaba a una nueva bifurcación, pero la memoria caché en servidores remotos seguía teniendo origin apuntando al depósito anterior, y por lo tanto no estaba encontrando nuevas confirmaciones que he enviado a la nueva bifurcación.

solucionado mediante la ejecución de cada uno de los servidores remotos:

git remote set-url origin <new fork>

7

Si está utilizando Capistrano eliminación de la (/ compartida) en caché copia debe resolver el problema.

+0

¡Este es mi problema! – neilmarion

+0

Me lo resolvió, muchas gracias! –

0

En mi caso, la rama git que estaba usando para una gema se fusionó en el maestro y se eliminó la rama. Actualizando mi Gemfile, eliminando Gemfile.lock, y volviendo a ejecutar bundle lo resolvió por mí.

6

Muchos de los carteles aquí son correctos, ya que probablemente tengan que ver con que Gemfile.lock no está sincronizado debido a que un repositorio se está moviendo o reubicando, pero como otros señalaron, eliminarlo no es una decisión acertada. decisión. Inspeccione Gemfile.lock y encuentre una entrada GIT para el repositorio en cuestión. Lo importante es comprobar a qué apunta el atributo de metadatos revision ... Lo más probable es que apunte a un hash de revisión incorrecto que ya no existe.

Mi consejo es editarlo manualmente para apuntar a la rama que desea desplegar haciendo una referencia cruzada con el archivo de registro Repo real (para asegurarse de que sea coherente con el que está realmente en su Gemfile real) de la siguiente manera :

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) 
0

Puede utilizar el indicador '--source' con 'paquete de actualización'. Por lo que será:

bundle update --source your_gem

0

Este problema se produce cuando se han producido cambios como fuerza empuja a un repositorio git que se hace referencia en un Gemfile.

La solución es comentar esa línea de gem en Gemfile, ejecutar bundle, descomentarlo y agruparlo de nuevo. Entonces, Gemfile.lock hará referencia a una revisión de git válida.

supongo que va a ayudar también: bundle update my_gem_name

0

estoy construyendo actualmente una joya y el problema era un poco diferente de las otras respuestas.

Apunto a una versión específica en el Gemfile pero para fines de desarrollo cambié el bundle config para obtener la versión local. Configuré una versión diferente en mi máquina local que hace que el objetivo Gemfile.lock sea diferente en el specs.

Este archivo se envía a través del servidor a través de git y el servidor obviamente no puede acceder a dicha versión de la gema ...

solucionarlo, basta con especificar una VERSION en su joya en consecuencia a la que usted' volver a desarrollar/empujar y debería estar bien.

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