git clone ¿falla el "paquete de índice"?

Así que creé un repositorio remoto que es no vacío (porque necesito redmine para poder leerlo), y está configurado para ser compartido con el grupo (entonces git init --shared = group). Pude presionar al repositorio remoto y ahora estoy intentando clonarlo.git clone ¿falla el "paquete de índice"?

Si clonarlo en la red me sale esto:

remote: Counting objects: 4648, done. 
remote: Compressing objects: 100% (2837/2837), done. 
error: git-upload-pack: git-pack-objects died with error.B/s 
fatal: git-upload-pack: aborting due to possible repository corruption on the remote side. 
remote: aborting due to possible repository corruption on the remote side. 
fatal: early EOF 
fatal: index-pack failed

soy capaz de clonar de forma local sin ningún problema, y me encontré con "fsck git", que sólo se informa de algunos árboles que cuelgan/manchas , que entiendo no son un problema ¿Qué podría estar causando esto? Todavía puedo sacarlo, solo no clonar. Debo señalar que la versión remota de Git es 1.5.6.5 mientras que local es 1.6.0.4

Traté de clonar mi copia local del repositorio, eliminando la carpeta .git y empujando a un nuevo repositorio, luego clonando el nuevo repositorio y Me sale el mismo error, lo que me lleva a creer que puede ser un archivo en el repositorio lo que está causando que git-upload-pack falle ...

Tengo un número de ventanas binarias en el repositorio, porque Acabo de construir los módulos de Python y luego los metí allí para que los demás no tuvieran que construirlos también. Si elimino los binarios de Windows y paso a un repositorio nuevo, puedo clonar nuevamente, quizás eso da una pista. Tratando de reducir exactamente qué archivo está causando el problema ahora.

Fuente

2009-12-22 Sean McAllister

lo digo, la clonación localmente acaba de hacer enlaces duros, por lo que no puede hacer 'índice-pak o detectar errores. –

Tengo ** exactamente los mismos mensajes de error **. Excepto que también trae docenas de los siguientes, todos repetidos, 'error: packfile .git/objects/pack/pack-5f2b4b46e2dba195a0fa5d29dfd3cef88067f8ed.pack no coincide con el índice' y' warning: '+ no se puede acceder a 'el mismo' pack 'msg +' . Solo ocurre cuando intentas clonar desde esta máquina específica. O bien, después de que falla, al intentar tirar también sucede. Más tarde parece que podemos seguir intentándolo hasta que finalmente termine. Cualquier otra máquina de clonación de ese repos no tiene ningún problema. El servidor ganador está vacío y todas las máquinas son ventanas con cygwin. – cregox

parece ser un error con cygwin; si lo intenta, podría funcionar. –

¿Se queja "git gc"?

Fuente

2009-12-22 08:50:35

No, parece funcionar bien. –

No sé cómo, pero al ejecutar ese comando primero lo arreglé para mí. –

mismo aquí, ejecutando 'git gc' antes de' git pull' solucionó el problema –

También tuve problemas con git cygwin, el error: fatal: index-pack failed,

que fue capaz de resolverlo mediante la creación de un montaje para mis proyectos y se establece a modo binario. ya que mi /c está configurado en modo de texto.

Añadir a /etc/fstab de cygwin:

c:/work/Projects /projects some_fs binary 0 0

plazo mount -a para montar todas las unidades.

Necesita estar en /projects para trabajar con cygwin git, /c/work/Projects fallará.

No estoy seguro si esto funcionará para usted.

Fuente

2011-02-23 18:53:39 mpmeyer

Tengo el mismo problema que usted; el mensaje de error cuando clon i:

Cloning into test... 
remote: Counting objects: 6503, done. 
remote: Compressing objects: 100% (4519/4519), done. 
Connection to git.myhost.im closed by remote host.| 350 KiB/s 
fatal: The remote end hung up unexpectedly 
fatal: early EOF 
fatal: index-pack failed

En mi caso, la razón es que el tamaño de mi repositorio (200M) es mayor que la memoria de mi git del servidor (128M). Cuando realizo la clonación desde el servidor git, uso el comando top en mi servidor, lo que muestra que el uso de la memoria supera los 128M.

Cuando uso otro servidor que tiene memoria 4G, el git clone está bien. También podría intentar agregar más espacio de intercambio a su servidor.

Fuente

2012-04-05 10:43:39 andywu

Agregando esto a '.gitconfig' fija: '[Core] packedGitLimit = 512m packedGitWindowSize = 512m [Pack] deltaCacheSize = 2047m packSizeLimit = 2047m windowMemory = 2047m' -, obviamente saltos de línea. –

Utilice la variable de entorno GIT_TRACE para obtener la salida de depuración. Establézcalo en "1" para rastrear hasta stderr o una ruta absoluta para rastrear hasta el archivo.

Fuente

2012-07-08 23:37:07

Tuve el mismo problema. También creo que esto tiene que ver con el hecho de que uso el modo texto/CRLF para los archivos creados. Y, de hecho, después de cambiar CygWin a modo de línea nueva UNIX/binario, todo funciona bien.

Ver:

Por cierto, la forma más fácil para mí para cambiar el modo de archivos se editar/etc/fstab para cambiar de

none /cygdrive cygdrive text,posix=0,user 0 0

none /cygdrive cygdrive binary,posix=0,user 0 0

Fuente

2012-12-10 20:32:27

Actualicé la fuente git de mi computadora cliente a la misma versión que el servidor se está ejecutando y eso solucionó esto por mí.

Fuente

2013-02-21 20:01:42

La manera en que resolví este problema es esta: mi git daemon se está ejecutando en Windows, y los clientes están en otras computadoras.

Encontré una solución alternativa (pero solo funcionará en Windows).

Iniciar el demonio Git con el modo de detalle de cmd.exe:

"C:\Program Files\Git\bin\sh.exe" --login -i -c 'git.exe daemon --verbose '

no han sido evaluados, si se trabaja directamente en bash git. Tal vez lo hará.

Luego (antes de iniciar cualquier copia, tire, busque, ...) seleccione un texto en la ventana (nota: "Modo de edición rápida" debe estar habilitado (se puede encontrar en: cmd.exe -> Propiedades (haga clic en la esquina superior izquierda de su ventana de cmd) -> Editar opciones) en la que se ejecuta git daemon. Eso evitará que imprima más mensajes en esa ventana.

Cuando el hilo de salida del demonio Git se bloquea esa manera, entonces el error no sucede

Fuente

2014-05-25 00:36:24 Martin

Bizarro, pero esto funcionó para mí también. 1. ejecuté git bash en windows 2. inicié un daemon (git daemon --verbose --export-all --reuseaddr --base-path =.) 3. marqué un texto (menú del sistema-> editar-> marque en el shell bash) 4. deje el texto marcado (no presione enter) y el daemon funciona correctamente (!), de lo contrario, error EOF anticipado en el cliente todo el tiempo. – codeSF

Funcionó para mí también ... –

Alternativa para la versión más reciente de git involucrado 1. Haga clic con el botón derecho en 2. ventana de opciones (déjela abierta mientras tira ..... :() – goofballLogic

tengo el mismo problema y me gustaría cambiar mis configuraciones Git y que se trabajó muy bien:

git config --global pack.packSizeLimit 50m
git config --global pack.windowMemory 50m
git config --global core.compression 9

Fuente

2017-02-15 19:45:27

puedo solucionar este problema mediante la fijación del permiso de carpeta:

sudo chmod 777 -R Your_folder

Fuente

2017-07-21 22:28:30 Lafriakh

git clone ¿falla el "paquete de índice"?

Respuesta

Cuestiones relacionadas