git pull falha "incapaz de resolver a referência" "incapaz de atualizar a referência local"

Usando o git 1.6.4.2, quando tentei um git pull, recebo este erro:

error: unable to resolve reference refs/remotes/origin/LT558-optimize-sql: No such file or directory
From git+ssh://remoteserver/~/misk5
 ! [new branch]      LT558-optimize-sql -> origin/LT558-optimize-sql  (unable to update local ref)
error: unable to resolve reference refs/remotes/origin/split-css: No such file or directory
 ! [new branch]      split-css  -> origin/split-css  (unable to update local ref)

Eu tentei git remote prune origin, mas não ajudou.

Tente limpar seu repositório local com:

$ git gc --prune=now
$ git remote prune origin

man git-gc (1):

git-gc - Cleanup unnecessary files and optimize the local repository

git gc [--aggressive] [--auto] [--quiet] [--prune=<date> | --no-prune]

       Runs a number of housekeeping tasks within the current repository, such as compressing file revisions
       (to reduce disk space and increase performance) and removing unreachable objects which may have been
       created from prior invocations of git add.

       Users are encouraged to run this task on a regular basis within each repository to maintain good disk
       space utilization and good operating performance.

man git-remote (1):

git-remote - manage set of tracked repositories

git remote prune [-n | --dry-run] <name>

           Deletes all stale remote-tracking branches under <name>. These stale branches have already been
           removed from the remote repository referenced by <name>, but are still locally available in
           "remotes/<name>".            

Isso também aconteceu comigo. No meu caso, o juiz ruim era o mestre, e eu fiz o seguinte:

rm .git/refs/remotes/origin/master
git fetch

Isso fez o git restaurar o arquivo ref. Depois disso tudo funcionou como esperado novamente.

Isso fez o trabalho para mim:

git gc --prune=now

Para mim, funcionou para remover os arquivos que estão gerando erros da pasta .git/refs/remotes/origin/.

Tente:

git gc --prune=now

git remote prune origin

git pull

Execute os seguintes comandos:

rm .git/refs/remotes/origin/master

git fetch

git branch --set-upstream-to=origin/master

Caso você precise saber o que é .git/refs/remotes/origin/master, leia a seção Remotes em Git References .

Gostaria apenas de acrescentar como pode acontecer uma quebra de referência.

Possível causa raiz

No meu sistema (Windows 7 de 64 bits), quando ocorre um BSOD , alguns dos arquivos de referência armazenados (provavelmente abertos / gravados no momento em que o BSOD aconteceu) são substituídos por NULLcaracteres (ASCII 0).

Como outros mencionados, para corrigi-lo, basta excluir esses arquivos de referência inválidos e buscar novamente ou puxar novamente o repositório.

Exemplo

Erro: cannot lock ref 'refs/remotes/origin/some/branch': unable to resolve reference 'refs/remotes/origin/some/branch': reference broken

Solução: exclua o arquivo%repo_root%/.git/refs/remotes/origin/some/branch

Eu tive esse mesmo problema e o resolvi indo para o arquivo em que estava com erro:

\repo\.git\refs\remotes\origin\master

Este arquivo estava cheio de nulos, substituí-o pela última referência do github.

No meu caso, o problema foi resolvido após a exclusão de todos os arquivos de referência de remoção no diretório .git.

Se você olhar para a mensagem, ela informará quais arquivos você precisa excluir (especificamente).

Os arquivos a serem excluídos estão abaixo .git/refs/remotes.

Acabei de excluir todos os arquivos de lá e executei o gc ameixa

git gc --prune=now

Depois disso, tudo funciona muito bem.

Explicação : Parece que suas ramificações de repositório remoto (no Github / bitbucket) foram removidas, embora suas referências locais não tenham sido atualizadas e apontando para referências inexistentes.

Para resolver este problema:

git fetch --prune
git fetch --all
git pull

Para leitura extra - Referência da documentação do Github :

git-fetch - Baixe objetos e referências de outro repositório

--all Buscar todos os controles remotos.

--prune Após a busca, remova quaisquer ramificações de rastreamento remoto que não existem mais no controle remoto.

git fetch --prune Corrigido este erro para mim:

[marc.zych@marc-desktop] - [~/code/driving] - [Wed May 10, 02:58:25]
[I]> git fetch
error: cannot lock ref 'refs/remotes/origin/user/janek/integration/20170505': 'refs/remotes/origin/user/janek/integration' exists; cannot create 'refs/remotes/origin/user/janek/integration/20170505'
From github.com:zooxco/driving
 ! [new branch]            user/janek/integration/20170505 -> origin/user/janek/integration/20170505  (unable to update local ref)
From github.com:zooxco/driving
[marc.zych@marc-desktop] - [~/code/driving] - [Wed May 10, 02:58:30]
[I]> git fetch --prune
 - [deleted]               (none)     -> origin/user/janek/integration

Isso pressupõe que a ramificação incorreta foi excluída no controle remoto.

Se esse erro "incapaz de atualizar a ref local" for recorrente, mesmo após aplicar a resposta de Vojtech Vitek ou Michel Krämer, você pode ter uma má ref no seu repositório local e mestre.

Nesse caso, você deve aplicar as duas correções sem puxar ou empurrar entre ...

rm .git/refs/remotes/origin/master
git fetch
git gc --prune=now
git remote prune origin

Uma resolução permanente para mim só foi alcançada após a aplicação de ambas as correções antes do push / pull.

Para responder a isso muito brevemente, esse problema ocorre quando o seu local possui algumas informações sobre o controle remoto e alguém altera algo que torna o controle remoto e suas alterações não sincronizadas.

Eu estava recebendo esse problema porque alguém excluiu a ramificação remota e criou novamente com o mesmo nome.

Para lidar com esses problemas, puxe ou busque no controle remoto.

git remote prune origin

ou se você estiver usando qualquer GUI, faça uma busca a partir do controle remoto.

Eu pude trabalhar com

git remote update --prune

Tente o seguinte:

git pull origin Branch_Name

Branch_Name, o ramo em que você está atualmente.

Se você fizer apenas um git pull, ele puxará todos os outros nomes de ramificações criados também.

Então é a razão pela qual você está recebendo isso:

! [new branch]      split-css  -> origin/split-css  (unable to update local ref)

Para mim, eu tinha um ramo local chamado feature/phase2e o ramo remoto foi nomeado feature/phase2/data-model. O conflito de nomenclatura foi a causa do problema; por isso, excluí minha ramificação local (você pode renomeá-la se houver algo que precise manter)

E se git gc --prune=now não ajudar você. (azar como eu)

O que fiz foi remover o projeto no local e clonar novamente o projeto inteiro.

Estou usando o Tower e, por algum motivo, meu nome de pasta era .git/refs/remotes/origin/Github. Mudar para minúsculas .git/refs/remotes/origin/githubresolveu o problema.

Eu tive o mesmo problema. sigo os seguintes passos

1) mude sua filial que tem problema para outra filial

2) excluir esse ramo

3) finalize a compra novamente.

Nota: - Você pode ocultar as alterações não confirmadas e colocá-las novamente.

Eu usei git prune origine isso fez o trabalho.

Eu tive o mesmo problema com a atualização do compositor. Mas, para mim, só funcionou depois de limpar o cache do compositor e excluir o conteúdo da pasta do fornecedor:

rm -rf vendor/*
git gc --prune=now
git pull
composer clear-cache
composer update my/package

Esse problema ocorreu ao tentar clonar a partir de um git bundlearquivo criado, nenhuma das outras respostas funcionou porque não consegui clonar o repositório (por isso, git gcremover / editar arquivos estava fora de questão).

No entanto, havia outra maneira de corrigir isso - o arquivo de origem de um .bundlearquivo estava começando com:

# v2 git bundle
9a3184e2f983ba13cc7f40a820df8dd8cf20b54d HEAD
9a3184e2f983ba13cc7f40a820df8dd8cf20b54d refs/heads/master
9a3184e2f983ba13cc7f40a820df8dd8cf20b54d refs/heads/master

PACK.......p..x...Kj.0...: (and so on...)

Simplesmente remover a quarta linha com o vim corrigiu o problema.

Eu tive esse problema ao usar o SourceTree. Eu tentei puxar novamente e funcionou. Eu acho que estava trabalhando nos galhos (checkout) muito rápido :).

Minha situação é um pouco diferente da do pôster, porque meu repositório tem sido relativamente cooperativo, sem nenhuma corrupção aparente.

 # remove the reference file of the branch "lost"
 rm -fv ./.git/refs/remotes/origin/feature/v1.6.9-api-token-bot-reader

 # get all the branches from the master
 git fetch --all

 # git will "know" how-to handle the issue from now on
 #     From github.com:futurice/senzoit-www-server
 # * [new branch]      feature/v1.6.9-api-token-bot-reader ->
 # origin/feature/v1.6.9-api-token-bot-reader

 # and push your local changes
 git push

Enfrentou o mesmo problema quando o repositório foi excluído e criado com o mesmo nome. Funcionou apenas quando reconfigurei o URL remoto como abaixo;

origem do conjunto de URLs remotos git [GIT_REPO_URL]

Verifique o URL remoto:

git remote -v

Agora, todos os comandos devem funcionar como de costume.

Acabei de encontrar o problema hoje.

Método de solução de problemas: Com o SourceTree nos servidores Windows, você pode tentar executá-lo como administrador. Isso corrige meu problema de "não é possível atualizar a ref local" na Atlassian Source Tree 2.1.2.5 em um Windows Server 2012 R2 no domínio.

Se você também pode replicar essa situação, isso prova que o problema é causado por um problema de permissão. É melhor detalhar e encontrar a causa raiz - provavelmente alguns arquivos específicos pertencem a outros usuários e outros - caso contrário, há um efeito colateral indesejável: você precisará executar o SourceTree como administrador pelo resto da eternidade.

Anote um caso específico que possa causar esse problema.

Um dia, empurrei uma ramificação chamada "feature / subfeature", enquanto mantinha a ramificação "feature" no controle remoto.

Essa operação funcionou bem, sem nenhum erro do meu lado, mas quando meus colegas de trabalho buscaram e / ou puxaram qualquer filial, todos eles tiveram exatamente a mesma mensagem de erro unable to update local ref,cannot lock ref 'refs/remotes/origin/feature/subfeature .

Isso foi resolvido excluindo featurebranch no remote ( git push --delete origin feature) e executando git remote prune originno repo dos meus colegas de trabalho, que gerava mensagens incluindo* [pruned] origin/feature .

Então, meu palpite é que git fetchestava tentando criar subfeatureref na featurepasta no git internamente (.git / ...), mas a criação da pasta falhou porque já havia featureref.

Temos esse problema quando um desenvolvedor no Mac criou uma ramificação com um símbolo maior que ">" no nome da ramificação.

Isso causou problemas no TeamCity e em computadores locais baseados no Windows executando o SourceTree. O BitBucket deixou passar sem problemas.

Para resolver, o usuário removeu a ramificação e a recriou. O que foi legal e fácil.

Tinha a mesma mensagem, mas com um diretório, recebia uma mensagem com falha na recepção.

O git --prone também não me ajudou. Acontece que havia um arquivo com o mesmo nome que um diretório criado remotamente.

Tinha que ir para .git \ logs \ refs \ remotes \ origin e apagar o arquivo de localidade - depois puxe novamente, tudo de bom.