avvertenza: HEAD remoto si riferisce a ref inesistente, impossibile effettuare il checkout


87

Questo sembra un errore comune per diverse cause.

Ho un semplice repository git nudo chiamato "kiflea.git", lo clono in questo modo:

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

Quindi git mi dice: warning: remote HEAD refers to nonexistent ref, unable to checkout.

E sì, non ci sono file con versione nella mappa, ad eccezione della directory .git. Ad ogni modo, l'unica cosa che devo fare è:

cd kiflea
git checkout master

E funziona, tutti i file sono lì. Ma ho pensato che la clonazione di un repository controlla automaticamente il master, quindi cosa sta succedendo esattamente e come lo risolvo?

Ho notato che, dopo aver fatto il git checkout masterbit, questo viene aggiunto al mio file di configurazione .git locale:

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

Probabilmente è interessante sapere che questo repository git era un repository svn in un lontano passato.

Ps: quando navighi nel repository nudo usando gitweb, c'è chiaramente un masterramo lì: http://kipdola.be/gitweb/?p=kiflea.git;a=summary


2
Cosa git ls-remote originti mostra?
CB Bailey

È lo stesso prima o dopo il checkout masterbit:25f600739343a7ce32d6311a1e6140870774810b refs/heads/master
skerit

1
Sembra che il repository remoto abbia perso (o non abbia mai avuto) il suo HEAD. Hai accesso diretto ad esso? Se è così, vedi qui
CB Bailey

1
Se cloni un repository e non specifichi il ramo, prova a usare il remote head. Come spiegato di seguito nelle risposte, non è possibile influenzare direttamente quale ramo. Tuttavia, controllando un ramo diverso al momento della clonazione, eviti questo controllo. Nel tuo caso sembra che il master esista ma la testa remota punta da qualche altra parte, quindi usa:git clone -b master <url> <dir>
eckes

Risposte:


128

Il warning: remote HEAD refers to nonexistent ref, unable to checkout. significa che il repository remoto (nudo) contiene riferimenti al ramo nel file chiamato HEADche non corrisponde a nessun ramo pubblicato nello stesso repository.

Nota che l'avviso significa solo che git non ha effettuato il checkout. Il repository clonato va bene per il resto. Basta faregit branch -a per vedere possibili rami egit checkout the-branch-you-want per risolvere il problema.

Questo di solito accade perché il contenuto predefinito per quel file ( .git/HEADo semplice HEADper i repository nudi) è ref: refs/heads/masterche dice che se qualcuno sta andando in clonequesto repository, dovrebbe per impostazione predefinita clonare il ramo refs/heads/master. Per impostazione predefinita, Git creerà un ramo locale senza il refs/heads/prefisso (ovvero, masterper impostazione predefinita). Provaregit help symbolic-ref per maggiori informazioni.

Il problema con questa situazione è che Git non fornisce un metodo per modificare i riferimenti simbolici remoti, quindi o usi qualcosa che il provider di hosting Git ha implementato (es. Impostazioni - ramo predefinito in GitHub se hai i diritti di amministratore) o devi usare il nome del ramo mastercome ramo predefinito (perché questo è il valore predefinito per quel riferimento simbolico).

Se hai accesso shell al tuo repository git remoto, puoi semplicemente cd path/to/bare/git/repo; git symbolic-ref HEAD refs/heads/XYZdove si XYZtrova il nome del ramo che desideri utilizzare per impostazione predefinita.

Un modo per risolvere questo problema è creare un nuovo repository nudo remoto senza commit e quindi fare git push name-of-the-remote my-special-branch-nameciò si tradurrà in un repository nudo contenente un singolo ramo my-special-branch-namema il riferimento HEADsimbolico contiene ancora il valore predefinito che punta master. Di conseguenza, riceverai l'avvertimento di cui sopra.


20
Nota che l'avviso significa solo che git non ha funzionato checkout. Il repository clonato va bene per il resto. Fare git branch -aper vedere possibili rami e git checkout the-branch-you-wantper "risolvere" il problema.
Mikko Rantalainen

2
Almeno si può evitare di usare la testina remota quando si usa git clone -b master(o qualunque sia il nome del ramo esistente).
eckes il

Ho fatto esattamente quello che hai scritto nell'ultimo paragrafo; Ci sono file nel ramo nel repository nudo (all'interno di gitlab) ma il clone sembra essere vuoto. {git branch -a} non mostra nulla. Anche {git clone -b nome-ramo-speciale <url>} sembra non funzionare (estremità remota bloccata).
Ed Randall

L'ho "risolto" copiando refs / remotes / my-special-branch-name in refs / heads e modificando HEAD in modo che corrisponda (nel repo gitlab nudo). Potrei quindi clonare con successo usando -b my-special-branch-name. Ma qual è il modo corretto per configurare il repository vuoto dopo il ciclo "init" / "push" in modo che clone -b non incontri problemi per favore?
Ed Randall

1
@EdRandall cd path/to/bare/git/repo; git symbolic-ref HEAD refs/heads/XYZdove XYZè il nome del ramo predefinito che vuoi usare se git cloneè fatto senza il -bflag. Se hai qualche altro problema, per favore, fai una nuova domanda invece di aggiungere domande come commenti.
Mikko Rantalainen

10

Ho avuto lo stesso problema perché non stavo più usando il masterramo ed è andato perso sia nel mio repository locale che in quello remoto.

Il repository remoto aveva ancora HEADimpostato su master, l'ho cambiato in uno dei rami remoti che uso effettivamente e tutto funziona bene.

Se puoi accedere al tuo repository remoto:

  • Vai al tuo remote_repo.git;
  • Modifica HEADfile
  • Modificare ref: refs/heads/master inref: refs/heads/your_branch

entrambe le condizioni sono possibili, il master è stato rimosso e la TESTA è ancora puntata verso di essa o la TESTA è stata modificata in un ramo che è stato rimosso successivamente. Immagino che (dal momento che il checkout dei master funziona) la seconda opzione sia il nostro caso. @MarcoBonifazi In quel caso il "cambio" sarebbe quello di sostituire broken_branchcon refs/heads/master.
eckes il

2
esiste un modo "corretto" per impostare il ramo HEAD in questo modo senza ricorrere alla modifica dei file?
Ed Randall

@EdRandall cd path/to/bare/git/repo; git symbolic-ref HEAD refs/heads/XYZdove XYZè il nome del ramo predefinito che vuoi usare se git cloneè fatto senza -bflag, come ho detto in un altro commento.
Mikko Rantalainen

7

Sì, questo è correlato al tuo clone git che tenta di eseguire il checkout di un ramo diverso dal master. Fallo e basta

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

Questo ti aiuterà a clonare il ramo esatto tramite il suo nome.


2

Anche se questo errore è stato visualizzato - il mio progetto era ancora connesso al repository corrispondente - ho eseguito il git branchcomando e ho visto i rami appropriati - quindi ho eseguito git checkout *branchnamee BOOM - tutto è andato bene.


Sì, @Mikko ha spiegato qual è il motivo. Se vuoi saltare il checkout, puoi usare l'opzione -b. (Ma è meglio riparare il tuo repository remoto a lungo termine!)
eckes il

1

C'è sicuramente qualcosa che non va nel tuo repository remoto. Potresti essere in grado di risolverlo creando un nuovo clone del repository. Anche il push di un nuovo commit sul ramo master potrebbe funzionare.


Immagino
volessi

1

Immagino che sia la parte iniziale *del log di commit che in qualche modo sta ingannando il server remoto.

Posso navigare nell'interfaccia web del repository utilizzando alcuni dei collegamenti del menu, ma altri falliscono con un 404 - Unknown commit objecto simile, in particolare dalla pagina di riepilogo.

Vedi se riesci a modificare l'ultimo messaggio di commit e quindi forza il push dell'aggiornamento per vedere se questo lo risolve. Potrebbe esserci un bug nel demone del server. Se risolve il problema, varrebbe la pena riportare sulla lista git git@vger.kernel.org (solo messaggi di testo normale)


1

Ho avuto lo stesso problema durante la creazione di un repository nudo.

L'ho risolto semplicemente clonando il repository, creando un ramo master locale e quindi spingendo master al repository remoto.

1) clona il repo

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

2) creare un ramo principale in locale.

   $ git checkout -b master

3) eseguire il commit di qualcosa nel ramo locale

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

4) Spingere il master locale sul telecomando

   $ git push origin master

0

Se non è effettivamente disponibile alcun ramo master, controllare quanto segue; Se nella cartella ".git" è presente un file denominato "pack-refs ", aprilo e troverai tutti i riferimenti elencati.

Qualcosa di simile sotto;

# 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

Quindi usa;

git checkout refs/tags/xxxx

O

git checkout 'HASH value'

per verificare la versione richiesta. Grazie.


0

Mi è sembrato di risolverlo con:

git checkout -b  master
git push

Questo ha creato il master predefinito e quindi ho potuto controllare i miei altri rami


0

Nel mio caso il repo era vuoto.

git checkout --orphan master

git add some_file
git commit -m 'init'
git push origin master 

0

Per Gitlab, anche se mostra che sei su un ramo predefinito (ad esempio master) potresti non esserci effettivamente, impostandolo di nuovo risolvilo, in questo modo:

  1. Crea un nuovo ramo, forse asd
  2. settings> repository> Default Branch, che mostra che il branch predefinito è master
  3. Impostalo su asd
  4. Impostalo di nuovo su master
  5. Elimina asdramo

Fatto, ora il tuo ramo predefinito è master

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.