aviso: HEAD remoto refere-se a ref inexistente, incapaz de verificar

86

Este parece ser um erro comum por diferentes causas.

Eu tenho um repositório git simples chamado "kiflea.git", eu o clono assim:

git clone git://kipdola.be/kiflea.git

Então git me diz: warning: remote HEAD refers to nonexistent ref, unable to checkout.

E sim, não há arquivos versionados no mapa, exceto para o diretório .git. De qualquer forma, a única coisa que preciso fazer é:

cd kiflea
git checkout master

E funciona, todos os arquivos estão lá. Mas pensei que a clonagem de um repo verifica automaticamente o master, então o que está acontecendo exatamente e como faço para corrigir isso?

Percebi que, depois de fazer a parte git checkout master, isso é adicionado ao meu arquivo de configuração .git local:

[branch "master"]
    remote = origin
    merge = refs/heads/master

Provavelmente é interessante saber que este repositório git costumava ser um repositório svn em um passado distante.

Ps: ao navegar no repositório básico usando gitweb, há claramente um masterbranch lá: http://kipdola.be/gitweb/?p=kiflea.git;a=summary

git 
— Skerit
fonte
2
O que git ls-remote originmostra a você?
— CB Bailey
É o mesmo antes ou depois do checkout masterbit:25f600739343a7ce32d6311a1e6140870774810b refs/heads/master
— skerit de
1
Parece que o repositório remoto perdeu (ou nunca teve) o seu HEAD. Você tem acesso direto a ele? Se sim, veja aqui
— CB Bailey
1
Se você clonar um repositório e não especificar o branch, ele tenta usar o cabeçote remoto. Conforme explicado abaixo nas respostas, você não pode influenciar qual ramificação diretamente. No entanto, ao verificar um branch diferente no momento da clonagem, você evita essa verificação. No seu caso, parece que o mestre existe, mas a cabeça remota aponta para outro lugar, então use:git clone -b master <url> <dir>
— eckes

Respostas:

125

Os warning: remote HEAD refers to nonexistent ref, unable to checkout.meios que o controle remoto (nua) repositório contém referência filial no arquivo chamado HEADque não corresponde a qualquer ramo publicada no mesmo repositório.

Observe que o aviso significa apenas que git não fez checkout. O repositório clonado está bem. Basta fazer git branch -apara ver possíveis ramificações e git checkout the-branch-you-wantcontornar o problema.

Isso geralmente acontece porque o conteúdo padrão para esse arquivo ( .git/HEADou simples HEADpara repositórios vazios) é ref: refs/heads/masterque diz que se alguém está indo para cloneeste repositório, eles devem por padrão clonar o branch refs/heads/master. Por padrão, o Git criará um branch local sem o refs/heads/prefixo (ou seja, masterpor padrão). Tente git help symbolic-refobter mais informações.

O problema com esta situação é que o Git não fornece um método para modificar simbólicas remotas, então você usa algo que o provedor de hospedagem Git implementou (por exemplo, Configurações - Branch padrão no GitHub se você tiver direitos de administrador) ou você tem que usar o nome do branch mastercomo o branch padrão (porque esse é o valor padrão para aquela referência simbólica).

Se você tiver acesso shell ao seu repositório git remoto, você pode simplesmente cd path/to/bare/git/repo; git symbolic-ref HEAD refs/heads/XYZonde XYZestá o nome do branch que deseja usar por padrão.

Uma maneira de resolver este problema é criar um novo git push name-of-the-remote my-special-branch-namerepositório vazio sem commits e então fazer o que resultará em um repositório vazio contendo um único branch, my-special-branch-namemas o HEADref simbólico ainda contém o valor padrão apontando para master. Como resultado, você receberá o aviso mencionado anteriormente.

— Mikko Rantalainen
fonte
20
Observe que o aviso significa apenas que o git não fez checkout. O repositório clonado está bem. Faça git branch -apara ver possíveis ramos e git checkout the-branch-you-want"consertar" o problema.
— Mikko Rantalainen
2
Pelo menos um pode evitar o uso do cabeçote remoto ao usar git clone -b master(ou qualquer que seja o nome do ramo existente).
— eckes
Fiz exatamente o que você escreveu no último parágrafo; Existem arquivos no branch no repositório básico (dentro do gitlab), mas o clone parece estar vazio. {git branch -a} não mostra nada. {git clone -b my-special-branch-name <url>} também não parece funcionar (a extremidade remota desligou).
— Ed Randall
Eu "consertei" copiando refs / remotes / my-special-branch-name para refs / heads e editando HEAD para corresponder (no repositório gitlab). Eu poderia então clonar com sucesso usando -b my-special-branch-name. Mas qual é a maneira correta de configurar o repositório vazio vazio após o ciclo "init" / "push" para que o clone -b não encontre problemas, por favor?
— Ed Randall
1
@EdRandall cd path/to/bare/git/repo; git symbolic-ref HEAD refs/heads/XYZonde XYZé o nome do branch padrão que você deseja usar se git clonefor feito sem o -bsinalizador. Se você tiver algum outro problema, por favor, faça uma nova pergunta em vez de adicionar perguntas como comentários.
— Mikko Rantalainen
10

Eu tive o mesmo problema porque não estava usando mais o master branch e ele se perdeu no meu repositório local e remoto.

O repositório remoto ainda tinha o HEADconjunto paramaster , eu mudei para um do branch remoto que eu realmente uso e tudo funciona bem.

Se você pode acessar seu repositório remoto:

  • Vá para sua remote_repo.git ;
  • Editar HEAD arquivo
  • Mudar ref: refs/heads/masterpararef: refs/heads/your_branch
— Marco Bonifazi
fonte
ambas as condições são possíveis, o master foi removido e o HEAD ainda aponta para ele ou o HEAD foi alterado para uma ramificação que foi removida posteriormente. Eu acho (desde a verificação das obras-primas) a segunda opção é o nosso caso. @MarcoBonifazi Nesse caso, a "mudança" seria substituir broken_branchpor refs/heads/master.
— eckes
2
existe uma maneira "adequada" de definir o branch HEAD como este, sem recorrer à edição dos arquivos?
— Ed Randall
@EdRandall cd path/to/bare/git/repo; git symbolic-ref HEAD refs/heads/XYZonde XYZé o nome do branch padrão que você deseja usar se git clonefor feito sem o -bsinalizador, como eu disse em outro comentário.
— Mikko Rantalainen
7

Sim, isso está relacionado ao seu clone git tentando fazer checkout em um branch diferente do master. Apenas faça isso

git clone user@git-server:project_name.git -b branch_name /some/folder

Isso o ajudará a clonar o branch exato por meio de seu nome de branch.

— pal4life
fonte
2

Mesmo que esse erro tenha sido exibido - meu projeto ainda estava conectado ao repositório correspondente - eu executei o git branchcomando e vi os branches apropriados - então eu executei git checkout *branchnamee BOOM - tudo estava bem.

— adswebwork
fonte
Sim, @Mikko explicou qual é o motivo. Se você quiser pular o check-out, pode usar a opção -b. (Mas é melhor consertar seu repo remoto no longo prazo!)
— eckes
1

Definitivamente, há algo errado com seu repositório remoto. Você pode consertá-lo fazendo um novo clone do repositório. Além disso, enviar um novo commit para o branch master também pode funcionar.

— Jason Axelson
fonte
Acho que você quis dizer: "git push -u origin HEAD: HEAD" Não resolveu nada para mim ...
— RzR
1

Eu acho que é o líder *no log de confirmação que de alguma forma está enganando o servidor remoto.

Posso navegar pela interface da web do repo usando alguns dos links de menu, mas outros falham com um 404 - Unknown commit objectou semelhante, principalmente na página de resumo.

Veja se você pode corrigir a última mensagem de confirmação e então forçar o envio da atualização para ver se isso corrige. Pode haver um bug no demônio do servidor. Se corrigir, valeria a pena relatar na lista git git@vger.kernel.org (apenas mensagens de texto simples)

— Philip Oakley
fonte
1

Eu tive o mesmo problema ao criar um repositório básico.

Resolvi isso apenas clonando o repo, criando um branch master local e enviando o master para o repo remoto.

1) clonar o repo

$ git.exe clone --progress -v "the remote path" "my local path"

2) criar um branch master localmente.

   $ git checkout -b master

3) cometer algo na filial local

$ git add readme.md 
$ git commit –m “Added readme”

4) Empurre o mestre local no remoto

   $ git push origin master
— Corrado
fonte
0

Se não houver um branch master realmente disponível, verifique o seguinte; Se houver um arquivo denominado 'pack-refs' dentro da pasta '.git', abra-o e você poderá encontrar todas as referências listadas.

Algo como abaixo;

# pack-refs with: peeled fully-peeled 
e7cc58650190bd28599d81917f1706445d3c6d8b refs/tags/afw-test-harness-1.5
^cfae4f034e82591afdf4e5ed72279297d0eee618
6afe1bcfa4bd74de8e0c8f64d024e1cc289206df refs/tags/afw-test-harness-2.1
^c32f7fa495d4b44652f46c065fcd19c3acd237a6
72f2e4284dfbf27c82967da096c6664646bbdd19 refs/tags/android-1.6_r1
^50992e805e758e2231f28ec2127b57a1a9fd0ddc
0cbd528cad1cee9556098b62add993fc3b5dcc33 refs/tags/android-1.6_r1.1

Em seguida, use;

git checkout refs/tags/xxxx

Ou 

git checkout 'HASH value'

para verificar a versão necessária. Obrigado.

— Samantha
fonte
0

Eu parecia consertar com:

git checkout -b  master
git push

Isso criou o mestre padrão, e então eu poderia verificar meus outros branches

— Brendan
fonte
0

No meu caso, o repo estava vazio.

git checkout --orphan master

git add some_file
git commit -m 'init'
git push origin master
— László Tóth
fonte
0

Para Gitlab, mesmo que ele mostre que você está em um branch padrão (por exemplo master), você pode não estar realmente nele, configurando-o novamente, corrija-o, assim:

  1. Crie uma nova filial, talvez asd
  2. configurações> repositório> Ramificação padrão, que mostra que a ramificação padrão é master
  3. Defina para asd
  4. Defina de volta para master
  5. Excluir asdramo

Pronto, agora seu branch padrão é master

— Ng Sek Long
fonte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.