Git pull erreur: impossible de créer temporaire sha1 nom de fichier

Il est mentionné dans "Re: Bug? git svn fetch: "impossible de créer temporaire sha1 nom de fichier /home/andres/git/public/cristal.g":

Après remballage le référentiel le problème a disparu. Vraiment étrange.

Avez-vous essayer un repack ?

git-repack est utilisé pour combiner tous les objets qui ne réside pas actuellement dans un "pack", dans un pack. Il peut également être utilisé pour ré-organiser les emballages existants en un seul, plus efficace pack.

Un pack est une collection d'objets, individuellement compressé, avec un delta de compression appliquée, stockées dans un fichier unique, associé à un fichier d'index.

Les Packs sont utilisés pour réduire la charge sur les systèmes de miroirs, de sauvegarde des moteurs, disque de stockage, etc.

Et avez-vous essayez de mettre à niveau vers la dernière version de Git ?

Vous ont différentes commandes à exécuter dans le but de "nettoyer" votre référentiel, à partir de la plus sûre pour les plus agressives:

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

---

Comme mentionné dans "Git la collecte des Ordures ne semble pas fonctionner totalement", un git gc --agressifs n'est ni suffisante, ni même assez sur son propre.

La combinaison la plus efficace serait l'ajout de git repack, mais aussi git prune:

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

Nous avons eu le même problème lorsque l'utilisateur 1 a commis auparavant, après quoi les objets/ed répertoire a été créé et détenu par l'utilisateur 1. Parce que l'utilisateur 1 autorisations par défaut ne permet pas l'écriture par l'utilisateur 2, utilisateur 2 ne pouvait pas s'engager.

git crée ces répertoires comme hachage seaux de quelque sorte sur la demande, de sorte qu'il est tout à fait possible pour eux d'être possédé par plusieurs personnes différentes avec des autorisations différentes en fonction de leur umask.

Nous l'avons résolu en premier chgrping tous les répertoires doivent être détenus par le même groupe, alors chmodding tous avec g+w de sorte qu'ils étaient un groupe droits d'écriture, et enfin tout le monde est umask correctement de sorte que tous les nouveaux seaux seront également accessible en écriture.

C'est parce que nous sommes à l'aide de ssh://Url à consulter à partir de git - je suppose que si nous étions à l'aide de git protocole de réseau il n'arriverait pas parce que le git daemon aurait cohérente de la propriété des fichiers.

Je vais avoir ce problème et se sentir comme j'ai essayé toutes les choses ci-dessus. J'avais vu ça avant, et c'était dû à des autorisations entre les différents utilisateurs en poussant à la mise en pension, mais dans ce cas tout le monde pousse sous le même utilisateur, et, pour faire bonne mesure, j'ai (sur le repo) chowned tout à la droite de l'utilisateur, le groupe et chmodded u+w et g+w pour faire bonne mesure. Je suis encore en train error: unable to create temporary sha1 filename ./objects/9a.

Je viens de faire un peu plus de l'enquête et il ne semble pas être quelque chose qui se passe avec les autorisations: avant la poussée, sur les pensions de titres (qui est un nu repo hébergé sur un serveur), tous les fichiers dans les objets ont des autorisations de -rw-rw-r-- ensemble, qui est ce que vous attendez. Ils sont tous détenus par le même utilisateur et de groupe. Après l'échec de pousser, je peux grep pour les fichiers avec les autorisations définies pour -r--r--r--, c'est à dire pas accessible en écriture par tout le monde, et affichent leurs emplacements à la commande bash find . -perm 444 | xargs ls -l. Faire que me donne la suivante:

-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

Ce sont toutes récemment changé de fichiers (au moment de la publication, c'est le 4 Novembre, 15:08). Ainsi, il ressemble à git est mise à jour/remplacer les fichiers (en leur donnant une nouvelle timestamp), de modifier les autorisations dans le processus, puis se plaindre sur les autorisations. Je suis totalement perplexe quant à ce qui se passe ici 🙁

Mon problème était un problème de permission

Je suis allé jusqu'répertoire cp-R repo repo_copy

puis tout a fonctionné à nouveau.

puis je suis allé à supprimer des pensions et le refus d'une autorisation, vérifié permanentes et permanentes avait été modifiée et que l'utilisateur je courais comme n'ont pas accès en écriture...

Si quelqu'un d'autre obtient cette erreur, je suis venu à travers elle lorsque vous travaillez à travers le windows-linux diviser. Semble que si un saut de ligne formats converti à windows, vous pouvez toujours engager dans certaines circonstances, mais git puis convertit linux format.

Donc, si de nouvelles lignes ont été les seuls à changer, nous avons maintenant eu deux identiques s'engage dans une rangée. Depuis commettre les hachages sont générés à partir de commettre un fichier de données, et chacun avait les mêmes données, ils ont terminé avec le même hash. Au moins dans mon cas, c'est ce que le "le Fichier existe déjà" l'indique. Git suis tout confus.

Je l'ai corrigé en faisant git reset --hard localement et sur le centre des pensions.

J'ai vu cette erreur une fois et suivis pour un problème d'autorisations. Je ne pouvais pas trouver comment il a été causé, mais de toute façon git avait couru comme un groupe qui n'avait pas l'autorisation d'écriture pour un objet d'annuaire.

Je ne vois pas de raison évidente dans le code et supposé que c'était un OS X les autorisations de problème, probablement à partir de certains bâclée faire ou installer.

Il convient de noter que vous avez besoin pour réparer les autorisations sur le référentiel que vous avez pousser à, non pas seulement pour votre travail.

J'ai des erreurs comme cela lorsque l'on travaille sur sshfs. Il répare lui-même après désinstallation et puis le montage de la partager à nouveau.

J'ai eu ce problème récemment et j'ai tout essayé sur ce fil avec pas de chance. Il y avait beaucoup d'espace disque sur mon VPS, mais il s'est avéré qu'en raison de ne pas le nettoyage de la déploiements dossier que j'avais dépassé les inodes limite (probablement en raison de la libs JS, j'ai été y compris avec 100s de fichiers avant de les croquant).

J'ai supprimé une charge de vieux déploiements et tout a bien fonctionné.

Je sais que c'est un peu un cas limite, mais c'est quelque chose à garder à l'esprit que si tout le reste échoue.