tipos tag example etiquetas crear git

tag - Cómo lidiar con este error de git



git push example (7)

Estoy obteniendo este error en mi repositorio de git:

22:09:15 $ git status # On branch master error: Could not read 8124cc15c63be92d534e4cdfa33c38d54deee122 error: unable to read tree object HEAD nothing to commit (working directory clean)

Una búsqueda de Google de error: unable to read tree object HEAD no resulta de mucha ayuda, este error parece ser muy raro. No estoy seguro de cómo lidiar con eso. ¿Podría ser una falla en el disco duro?

Editar : La salida de git fsck es la siguiente:

broken link from commit 607328dc80e4901a55b95c683d4fbf43e6df28bf to tree 8124cc15c63be92d534e4cdfa33c38d54deee122 missing tree 8124cc15c63be92d534e4cdfa33c38d54deee122 dangling tree 56b5d4a5e429d251582ec927bca7ef1225510c41 dangling tree 0259d2d38b18b6136bb6070fb41faf3624453cc6

En un mensaje de "enlace roto", puede seguir las recomendaciones de GitFaq :

  • respalda todo tu estado para que todo lo que hagas sea posible de nuevo si corrompes las cosas más.
  • explotar cualquier paquete corrupto de archivos
    • Consulte " man git-unpack-objects " y, en particular, el indicador " -r ".
      Además, tenga en cuenta que solo desempaqueta objetos que aún no están disponibles, por lo que debe alejar el archivo de paquete de su ubicación normal primero (de lo contrario, git-unpack-objects encontrará todos los objetos que se encuentran en el archivo de paquete en el archivo de paquete en sí, y no descomprimir nada en absoluto)
  • reemplazar cualquier objeto roto y / o faltante
    • Esta es la parte desafiante.
      A veces (¡con suerte!) Puede encontrar los objetos faltantes en otras copias de los repositorios.
      En otras ocasiones, es posible que deba intentar buscar los datos de alguna otra forma (por ejemplo, ¿tal vez su copia comprobada contiene el contenido del archivo que cuando hashed será el objeto faltante?).
  • asegúrate de que todo esté satisfecho con " git fsck --full "
  • vuelva a empacar todo para volver a un estado eficiente de nuevo

Notas:

Actualice julio de 2016 (7 años más tarde), y pronto se lanzará Git 2.10, ahora tiene:

git fsck --name-objects

Ayuda a nombrar el origen de esos enlaces rotos

Consulte " Cómo solucionar el error del enlace error de git de un árbol a otro " para obtener más información.

Obtuve un error similar en el repositorio Git de mi instalación Homebrew . En lugar de restaurar todos los objetos que faltan uno por uno, me resultó más fácil simplemente eliminar el directorio .git y crearlo de nuevo al volver a clonar desde el repositorio público de Homebrew . Estos fueron mis pasos:

  • Compruebe qué información tiene en su repositorio de Git que no obtendrá con solo volver a clonar. Para mí, se trataba de ramas privadas, escondites y controles remotos.
    • Convierta stashes en commits reales creando una nueva rama, aplicando el alijo, y cometiendo algo como "[WIP]" en el nombre para mostrar que es un alijo.
    • Guarde las ramas que no están en el control remoto público empujándolas a su propio control remoto. Esto podría ser una bifurcación del repositorio en GitHub, o simplemente un nuevo repositorio de Git en una ubicación diferente en su máquina.
    • Si tiene más de un control remoto, guarde la salida de git remote -v , que contiene los nombres y las direcciones URL de sus controles remotos, para que pueda volver a agregarlos manualmente más tarde.
  • Borre el directorio .git su repoistory (o cambie el nombre a .git-broken y elimínelo más adelante). En la línea de comandos, este es rm -rf .git .
  • Vuelva a clonar el directorio remoto con git clone https://github.com/Homebrew/homebrew.git o cualquier URI.
  • Esto creará una nueva subcarpeta homebrew nombrada después del repositorio. Solo quiere el directorio .git de eso; sus archivos locales ya están bien. Así que mv homebrew/.git .git , y luego elimine la carpeta homebrew .
  • Su repositorio de Git no debería tener errores, ya que lo recreó desde cero. Ahora solo restaure la información que guardó en el primer paso.
    • Si tenía controles remotos adicionales, agréguelos nuevamente con git remote add <name> <url> .
    • Si realizó una copia de seguridad de las ramas (o depósitos convertidos en ramas) en un depósito remoto, extráigalos de ese depósito a su depósito local.
    • Si lo desea, puede convertir los stash-branches en stashes pasando el "[WIP]" commit con git reset HEAD^ y guardando el directorio de trabajo en un stash nuevamente con git stash save <custom-message> .

Si ejecuta git fsck , no debería ver ningún error:

$ git fsck Checking object directories: 100% (256/256), done. Checking objects: 100% (197135/197135), done. Checking connectivity: 197162, done. $

Y git stash list , git branch y git remote -v deberían mostrar el mismo resultado que antes.

Si no tiene cambios sin compromiso, la solución más fácil es eliminar la sucursal local: git branch -D [branch name]

y luego pagar de nuevo la rama remota: git checkout -b [nombre de la rama] origen / [nombre de la sucursal]

Solucioné el error haciendo cambios en la misma carpeta de directorio / proyecto y luego intenté confirmar el nuevo cambio. Lo que sucedió es que obtuve un mensaje de error. Objeto inválido 100644 e38e910ceb18b09f436f353c3a131bfe2caba130 para ''Book / alise_mathe / app / src / main / res / menu / drawermenu.xml ''este mensaje solucionó el problema, simplemente refactoré el archivo drawermenu.xml cambiando el nombre del archivo a'' menú_cajón.xml ''. agregó los cambios cometidos y eso es todo. (android-studio)

Espero que esto ayude de alguna manera

Solucioné este error eliminando la carpeta Capistrano ''repo'' de mi directorio de servidor remoto. Revisé varios de los otros problemas sugeridos y resolví que el problema no estaba en mi proyecto local. El problema parecía ocurrir cuando Capistrano estaba ejecutando tirando del repositorio al control remoto. Para mí, esto se debió quizás a una implementación detenida que dejó objetos dañados / referencias a objetos. Mi host también acaba de hacer una migración de servidor, tal vez algo se corrompió durante este proceso.

Tuve un problema similar en este momento. La corrupción surgió cuando mi computadora portátil se apagó duramente durante un git pull . Tengo un repositorio de copia de seguridad remota. Primero tuve varios archivos de objetos en .git / objects / ?? / * que eran de tamaño cero. Después de una copia de seguridad cp -a del repositorio, hice esto:

  • eliminar los objetos de longitud cero
  • clonar el repositorio remoto en un ../fresh/ repositorio

  • en el repositorio roto, lo hice

    cat ../fresh/.git/objects/pack/pack-*.pack | git unpack-objects

Esto llenó los objetos faltantes en la base de datos de objetos. El repositorio parece estar copia de seguridad ahora.

Yo tuve el mismo problema. Después de mucho tirón de pelo, descubrí que se debía a un cambio de permiso en los archivos git del repositorio. Lo he resuelto de la siguiente manera:

$ cd .git $ chmod 755 *

¡Hecho!