Error de extracción de Git: no se puede crear el nombre de archivo sha1 temporal

Question

Tengo una pequeña configuración de git repo con el único propósito real de poder desarrollar localmente en varias máquinas (trabajo, hogar, computadora portátil). Por lo tanto, tengo una rama y me comprometo/empujo una vez que salgo de una computadora, tire una vez que me siento en la siguiente. Ha funcionado bien, hasta ahora eso es todo. Ahora cuando me tire en mi máquina 'prueba en vivo', me sale el siguiente:

remote: Counting objects: 38, done. 
remote: Compressiremote: ng objects: 100% (20/20), done. 
remote: Total 20 (delta 17), reused 0 (delta 0) 
error: unable to create temporary sha1 filename .git/objects/ed: File exists 

fatal: failed to write object 
fatal: unpack-objects failed 

Buscando en la red la única verdadera respuesta que pude encontrar fue la siguiente: http://marc.info/?l=git&m=122720741928774&w=2 que básicamente afirma que esto es un error falso que es encima de la pila y, por lo tanto, no dice nada sobre lo que realmente está mal.

¿A dónde voy desde aquí para descubrir cuál es el problema?

Editar: Se ha eliminado la copia local y re-clonado

Answer 1

Por lo que vale, cuando tuve este problema, pero al cometerlo, intenté git-repack y git-gc, pero ninguno funcionó. Obtuve un error de permiso denegado, lo que me llevó a chown todo el repositorio de forma recursiva para el usuario que esperaba, y luego pude confirmar/empujar/tirar sin ningún problema.

Answer 2

Se menciona en "Re: Bug? git svn fetch: "unable to create temporary sha1 filename /home/andres/git/public/crystal.g":

After repacking the repository the problem is gone. Really rather strange.

¿Usted intentó un repack?

git-repack is used to combine all objects that do not currently reside in a "pack", into a pack. It can also be used to re-organize existing packs into a single, more efficient pack.
A pack is a collection of objects, individually compressed, with delta compression applied, stored in a single file, with an associated index file.
Packs are used to reduce the load on mirror systems, backup engines, disk storage, etc.

¿Y trataste de actualizar a la última versión de Git?

Usted have different commands a ejecutar con el fin de "limpiar" su repositorio, desde el más seguro para los más agresivos:

$ git-prune 
$ git-gc --aggressive 
$ git-repack 
$ git-repack -a 
$ git-prune-packed 

---

Como se mencionó en "Git Garbage collection doesn't seem to fully work", un git gc --aggressive no es ni suficiente ni siquiera suficiente por sí mismo.

La combinación más efectiva sería la adición de git repack, sino también git prune:

git gc 
git repack -Ad  # kills in-pack garbage 
git prune   # kills loose garbage 

Answer 3

que he visto este error de una vez y lo rastreó a un problema de permisos. No pude encontrar cómo se había causado, pero de alguna manera git se había ejecutado como un grupo que no tenía permiso de escritura para algún directorio de objetos.

No encontré ninguna razón obvia para ello en el código y formulé la hipótesis de que era un problema de permisos de OS X, presumiblemente debido a una instalación o instalación descuidada.

Answer 4

Mi problema era un problema de permisos

subí directorio, cp -R repo repo_copy

luego todo volvió a funcionar.

Luego fui a eliminar el repositorio y el permiso denegado, revisé las permanentes y había cambiado las permanentes que el usuario que estaba ejecutando no tenía acceso de escritura ...

Answer 5

Tuvimos el mismo problema en el que el usuario 1 se había comprometido previamente, con lo que el directorio objects/ed fue creado y propiedad del usuario 1. Debido a que los permisos predeterminados del usuario 1 no permitían escribir por el usuario 2, el usuario 2 no pudo confirmar.

git crea estos directorios como contenedores de hash de algún tipo bajo demanda, por lo que es bastante posible que sean propiedad de varias personas con diferentes permisos según su umask.

Lo solucionamos agrupando primero todos los directorios para ser propiedad del mismo grupo, luego compilándolos todos con g + w para que fueran editables por grupo, y finalmente configurando umask de todos correctamente para que todos los cubos recién creados también sean grupo escribible.

Esto se debe a que estamos usando ssh: // URLs para retirar de git - Supongo que si estuviéramos usando el protocolo de red git no sucedería porque el daemon git tendría una propiedad consistente de archivos.

Answer 6

que he visto este error cuando varios usuarios se comprometen con el mismo repositorio, lo que resulta en problemas de permisos de grupo de lectura-escritura como consecuencia de ssh and umask

Puede hacer nuevos archivos conservan el modo de g + w mediante el establecimiento de sharedrepository=true la sección [core] de config:

cd /my/shared/repo.git 
git repo-config core.sharedRepository true 

# (might also need to "chmod -R g+wX ." for each 
# user that owns files in .git/objects) 

EDIT:

Este método es sólo se aplica a pases ya existentes. Puede hacerlo bien una vez en la creación del repositorio: git --bare init --shared.

Answer 7

En mi caso, tuve este problema al intentar presionar.

dieter@dieter-dellD620-arch sugarcrmclient [master] git push origin 
Counting objects: 16, done. 
Delta compression using up to 2 threads. 
Compressing objects: 100% (10/10), done. 
Writing objects: 100% (12/12), 3.91 KiB, done. 
Total 12 (delta 1), reused 11 (delta 1) 
error: unable to create temporary sha1 filename ./objects/7a: File exists 

fatal: failed to write object 
error: unpack failed: unpacker exited with error code 
To gitosis@tiktak.kangaroot.net:sugarcrmclient.git 
! [remote rejected] master -> master (n/a (unpacker error)) 
! [remote rejected] web -> web (n/a (unpacker error)) 
error: failed to push some refs to 'gitosis@tiktak.kangaroot.net:sugarcrmclient.git' 

no fue un problema de permiso. git gc, git gc --agrressive, git repack o git prune localmente no ayudaron. Observe cómo el error dice "error de desempaquetado", creo que es la clave, porque implica que está en el otro lado. Así que fui al repositorio (desnudo) e hice un git gc allí. Entonces podría empujar bien.

Answer 8

Tuve un error similar, y no era un problema de permisos (soy el único usuario del repositorio), y ninguna de las técnicas de gc/reempaquetar funcionó. En última instancia, simplemente dejé de lado el antiguo repositorio remoto y empujé uno nuevo. Afortunadamente, era bastante pequeño.

Liam

Answer 9

Cabe señalar que es necesario fijar los permisos en el repositorio que usted está empujando a, no sólo su funcionamiento uno.

Answer 10

Cambio de grupo de usuarios + permiso funcionó para mí. Me di cuenta de que las confirmaciones de algunos usuarios estaban en otro grupo. Cambiar todo al mismo grupo solucionó este problema.

Answer 11

Recibo errores como este cuando trabajo sobre sshfs. Se repara luego de desmontarlo y luego volver a montarlo.

Answer 12

Intenté algunas de las soluciones, pero finalmente me di cuenta de que el disco de nuestro servidor git no tenía espacio libre.

Answer 13

Si alguien más obtiene este error, lo he encontrado al trabajar a través de la división windows-linux. Parece que si los formatos de nueva línea se convierten a Windows, aún así puede comprometerse en algunas circunstancias, pero git luego se convierte a formato de Linux.

De modo que si las nuevas líneas fueran el único cambio, entonces ahora teníamos dos compromisos idénticos seguidos. Como los hash de confirmación se generan a partir de datos de archivo de confirmación y cada uno tenía la misma información, terminaron con el mismo hash. Al menos en mi caso, eso es lo que indica el "Archivo existe". Git se confundió.

Lo arreglé haciendo git reset --hard localmente y en el repositorio central.

Answer 14

Trabajando en el servidor linux a mac local - Probé algunas de las sugerencias anteriores sin suerte. Reiniciado y luego funcionó.

No es realmente una solución adecuada, pero creo que podría ayudar a alguien por ahí.

Answer 15

Personalmente, tuve este problema cuando hice un master de origen de git push. La solución para mí fue: En mi servidor, me conecto con la raíz en el directorio que contiene mi repositorio y lo hacen de forma recursiva:

chown -hR MyGitUser MyRepo 

y todo trabaja muy bien

tengo sólo un usuario git y otros Conéctese con ssh publicando su clave pública. Si configura varios usuarios de git, debe hacer lo mismo para cada usuario.

Answer 16

Tengo este problema y siento que he intentado todas las cosas anteriores. Lo había visto antes y era debido a los permisos entre diferentes usuarios que empujaban al repositorio, pero en este caso todos presionan al mismo usuario, y en buena medida, he (en el repositorio) lo he probado todo para el usuario correcto. y agrupe y modifique u + w y g + w para una buena medida. Todavía estoy recibiendo error: unable to create temporary sha1 filename ./objects/9a.

Acabo de investigar un poco más y parece que está pasando algo con los permisos: antes del empuje, en el repositorio (que es un repositorio simple alojado en un servidor), todos los archivos en objetos tienen permisos de -rw-rw-r-- conjunto, que es lo que esperas. Todos son propiedad del mismo usuario y grupo. Después del intento fallido, puedo grep para archivos con los permisos establecidos en -r--r--r--, es decir, no se puede escribir por nadie, y mostrar sus ubicaciones con el comando bash find . -perm 444 | xargs ls -l. Hacer eso me da lo siguiente:

-r--r--r-- 1 ourusername ourgroupname 730 Nov 4 15:02 ./objects/46/346f550340bc0d3fec24ea42b25999161f8c7a 
-r--r--r-- 1 ourusername ourgroupname 177 Nov 4 15:02 ./objects/4c/664ebbfad568de6101a52c01f5117654945d6d 
-r--r--r-- 1 ourusername ourgroupname 730 Nov 4 14:36 ./objects/9e/3f572366da9fb319331dfd924ae35cf9fd00ae 
-r--r--r-- 1 ourusername ourgroupname 175 Nov 4 14:36 ./objects/aa/f42d7ed706f1d2e4a0aa1c5eb184e17e917204 

Estos son todos los archivos modificados recientemente (en el momento de la publicación es Nov 4, 15:08). Entonces, parece que git está actualizando/reemplazando los archivos (dándoles una nueva marca de tiempo), cambiando los permisos en el proceso y luego quejándose de los permisos. Estoy totalmente confundido en cuanto a lo que está pasando aquí :(

Answer 17

me encontré con este problema cuando se utiliza git push

Luego ejecutar git gc, funciona

De git-gc (1) Manual de página.:

git-gc -. archivos innecesarios de limpieza y optimizar el repositorio local

Answer 18

he tenido este problema cuando se trata de desplegar en heroku Resulta que tenía una joya que escribió un archivo en el tmp/y heroku didn' me gusta eso Sacó el archivo y listo, problema resuelto. Ver esto: https://devcenter.heroku.com/articles/read-only-filesystem

Answer 19

Tuve este problema recientemente y probé todo en este hilo sin suerte.Había mucho espacio en el disco en mi VPS pero resultó que debido a que no había limpiado la carpeta de implementaciones, había excedido el límite de inodos (probablemente debido a las libs de JS que incluía cientos de archivos antes de procesarlos).

Eliminé una carga de implementaciones antiguas y todo funcionó bien.

Me doy cuenta de que se trata de un caso marginal, pero es algo a tener en cuenta si todo lo demás falla.