Git pull error: não foi possível criar o nome do arquivo sha1 temporário

Eu tenho uma pequena configuração de repository git com o único propósito real de ser capaz de desenvolver localmente em várias máquinas (trabalho, casa, laptop). Assim, eu tenho um ramo e me comprometo / empurro uma vez que saio de um computador, puxo uma vez que me sento no seguinte. Funcionou bem, até agora isso é. Agora, quando eu puxo a minha máquina de ‘teste ao vivo’, recebo o seguinte:

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 

Pesquisando em torno da net a única resposta real que eu poderia encontrar foi o seguinte: http://marc.info/?l=git&m=122720741928774&w=2 que basicamente afirma que este é um erro falso que está no topo da pilha e, portanto, não diz nada sobre o que realmente está errado.

Para onde eu vou daqui para descobrir o que está errado?

Editar: removeu a cópia local e foi clonada novamente

Por que vale a pena, quando eu tive esse problema, mas ao cometer, eu tentei git-repack e git-gc , mas nem funcionou. Eu recebi uma permissão negada erro, o que me levou a chown o repo inteiro de forma recursiva para o usuário que eu esperava que fosse, e eu poderia então comprometer / empurrar / puxar sem nenhum problema.

É mencionado em ” Re: Bug? Git svn fetch:” não é possível criar o arquivo sha1 temporário /home/andres/git/public/crystal.g “:

Depois de reembalar o repository, o problema desapareceu. Realmente bastante estranho.

Você tentou um empacotamento?

git-repack é usado para combinar todos os objects que não residem atualmente em um “pacote”, em um pacote. Ele também pode ser usado para reorganizar os pacotes existentes em um único pacote mais eficiente.
Um pacote é uma coleção de objects, compactados individualmente, com compactação delta aplicada, armazenados em um único arquivo, com um arquivo de índice associado.
Os pacotes são usados ​​para reduzir a carga em sistemas espelhados, mecanismos de backup, armazenamento em disco, etc.

E você tentou atualizar para a versão mais recente do Git?

Você tem comandos diferentes para executar para “limpar” seu repository, do mais seguro para o mais agressivo:

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

Como mencionado em ” A garbage collection do Git não parece funcionar totalmente “, um git gc --aggressive não é suficiente ou mesmo suficiente por conta própria.

A combinação mais eficaz seria adicionar o git repack , mas também git prune :

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

Eu vi esse erro quando vários usuários se comprometem com o mesmo repository, resultando em problemas de permissão de gravação em grupo como consequência de ssh e umask

Você pode fazer com que novos arquivos retenham o modo g + w definindo sharedrepository=true na seção [core] da configuração:

 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) 

EDITAR:

Este método é aplicável apenas a repos já existentes. Você pode fazer certo uma vez na criação do repository: git --bare init --shared .

Tivemos o mesmo problema em que o usuário 1 havia se comprometido anteriormente, após o que o diretório objects / ed foi criado e de propriedade do usuário 1. Como as permissions padrão do usuário 1 não permitiam a gravação pelo usuário 2, o usuário 2 não podia confirmar.

O git cria esses diretórios como hashes de hash de algum tipo sob demanda, então é bem possível que eles sejam de propriedade de várias pessoas diferentes com permissions diferentes de acordo com sua umask.

Nós resolvemos isso primeiro chgrping todos os diretórios para pertencer ao mesmo grupo, em seguida, chmodding todos com g + w para que eles eram grupo gravável e, finalmente, definir umask de todos corretamente para que todos os intervalos recém-criados também serão graváveis ​​em grupo.

Isso ocorre porque estamos usando URLs ssh: // para fazer o check-out do git – suponho que, se estivéssemos usando o protocolo de rede git, isso não aconteceria porque o daemon do git teria uma propriedade de arquivo consistente.

No meu caso, tive esse problema ao tentar empurrar.

 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' 

não foi um problema de permissão. git gc, git gc –agressivo, git repack ou git prune localmente não ajudou. Note como o erro diz “erro de desempacotamento”, acho que é fundamental, porque implica que está do outro lado. Então eu fui ao repository (nu) e fiz um git gc lá. Então eu poderia empurrar bem.

Estou tendo este problema e sinto que tentei todas as coisas acima. Eu tinha visto isso antes e foi devido a permissions entre diferentes usuários empurrando para o repository, mas neste caso todo mundo empurra sob o mesmo usuário, e apenas para uma boa medida eu (no repository) chowned tudo para o usuário certo e agrupar e chmodded u + we g + w para uma boa medida. Ainda estou recebendo error: unable to create temporary sha1 filename ./objects/9a .

Acabei de fazer um pouco mais de investigação e parece haver algo acontecendo com permissions: antes do push, no repository (que é um -rw-rw-r-- hospedado em um servidor), todos os arquivos em objects têm permissions de -rw-rw-r-- set, que é o que você esperaria. Todos pertencem ao mesmo usuário e grupo. Após o push com falha, eu posso procurar por arquivos com as permissions definidas como -r--r--r-- , isto é, não gravável por ninguém, e exibir seus locais com o comando bash find . -perm 444 | xargs ls -l find . -perm 444 | xargs ls -l find . -perm 444 | xargs ls -l . Fazendo isso me dá o seguinte:

 -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 

Estes são todos os arquivos recentemente alterados (no momento da publicação é 4 de novembro, 15:08). Então, parece que o git está atualizando / substituindo os arquivos (dando a eles um novo timestamp), alterando as permissions no processo, depois reclamando das permissions. Estou totalmente perplexo com o que está acontecendo aqui 🙁

Eu encontrei esse problema ao usar o git push

Então eu corro git gc , funciona.

De git-gc (1) Página Manual:

git-gc – Limpa arquivos desnecessários e otimiza o repository local

Meu problema foi um problema de permissão

Eu fui até o diretório então cp -R repo repo_copy

então tudo voltou a funcionar.

então eu fui para excluir o repo e a permissão negada, perms verificados e perms o suficiente tinha sido alterado que o usuário que eu estava executando como não tinha access de gravação …

Pessoalmente, eu tenho esse problema quando eu fiz um mestre de origem git push. A solução para mim foi: No meu servidor, eu faço o login com root no diretório que contém meu repository e faço recursivamente:

 chown -hR MyGitUser MyRepo 

e tudo funciona bem

Eu tenho apenas um usuário git e outros se conectam com o ssh publicando sua chave pública. Se você configurar vários usuários git, você terá que fazer o mesmo para cada usuário.

Se alguém mais receber esse erro, eu o encontrei quando trabalhei na divisão windows-linux. Parece que, se os formatos de nova linha forem convertidos em janelas, você ainda poderá confirmar em algumas circunstâncias, mas o git será convertido para o formato linux.

Então, se novas linhas fossem a única mudança, agora nós tínhamos dois commits idênticos seguidos. Como os hashes de confirmação são gerados a partir dos dados do arquivo de confirmação e cada um possui os mesmos dados, eles acabam com o mesmo hash. Pelo menos no meu caso, é o que o “Arquivo existe” indica. Git ficou todo confuso.

Eu git reset --hard lo, fazendo git reset --hard localmente e no git reset --hard central.

Tentei algumas das soluções, mas finalmente percebi que o disco do nosso servidor git não tinha espaço livre à esquerda.

Eu vi esse erro uma vez e segui-lo para um problema de permissions. Não consegui descobrir como isso foi causado, mas de alguma forma o git tinha sido executado como um grupo que não tinha permissão de gravação para algum diretório de objects.

Eu não vi nenhuma razão óbvia para isso no código e especifiquei que era um problema de permissions do OS X, presumivelmente de algum make ou instalação desleixado.

Eu tive um erro semelhante, e não foi um problema de permissions (eu sou o único usuário do repository), e nenhuma das técnicas de gc / repack funcionou. Em última análise, eu apenas mudei de lado o antigo repository remoto e empurrei um novo. Felizmente era bem pequeno.

Liam

Deve-se notar que você precisa consertar as permissions no repository para o qual você está empurrando, e não apenas o que você está trabalhando.

Alterar o grupo de usuários + permissão funcionou para mim. Eu notei que alguns commits de usuários estavam em grupos diferentes. Alterar tudo para o mesmo grupo resolveu esse problema.

Eu recebo erros assim ao trabalhar com sshfs. Ele se repara depois de desmontar e montar o compartilhamento novamente.

Trabalhando no servidor linux para o mac local – eu tentei algumas das sugestões acima sem sorte. Reiniciei e depois funcionou.

Não é realmente uma solução adequada, mas eu acho que pode ajudar alguém lá fora.

Eu tive esse problema ao tentar implantar no heroku. Acontece que eu tinha uma gem que escreveu um arquivo para o diretório tmp / e heroku não gostou disso. Tirou o arquivo e voila, problema resolvido. Veja isto: https://devcenter.heroku.com/articles/read-only-filesystem

Eu tive esse problema recentemente e tentei tudo neste segmento sem sorte. Havia muito espaço em disco sobrando no meu VPS, mas descobriu-se que, devido a não limpar a pasta de implementações, eu tinha excedido o limite de inodes (provavelmente devido às bibliotecas JS que eu estava incluindo com centenas de arquivos antes de processá-las).

Eu apaguei uma carga de implementações antigas e tudo funcionou bem.

Eu percebo que isso é um pouco difícil, mas é algo para se ter em mente se tudo mais falhar.