FETCH_HEAD riferimento non si aggiorna correttamente dopo "git fetch"

Question

Ho un repository locale che estrae da uno remoto. Esecuzione git pull nonché git fetch; git merge FETCH_HEAD utilizzato per eseguire esattamente la stessa azione, come previsto dalla description of git pull:

DESCRIZIONE

incorpora cambiamenti da un repository remoto nel ramo corrente. Nella sua modalità predefinita, git pull è una scorciatoia per git fetch seguito da git merge FETCH_HEAD.

Attualmente, e inaspettatamente, correndo git fetch fermato aggiornare correttamente il riferimento FETCH_HEAD. FETCH_HEAD è ora bloccato su un vecchio commit. L'esecuzione di git fetch scarica tutte le modifiche ai rami di monitoraggio remoto, ma FETCH_HEAD rimane invariato indipendentemente dal ramo in cui viene eseguito.

# currently in branchone 
> git fetch 

# branchone is up to date since... 
> git rev-parse branchone 
593539e8a98ba5980d4b645db3b0f506bb9b6a2c 

# ...its in the same commit as the remote branch 
> git rev-parse origin/branchone 
593539e8a98ba5980d4b645db3b0f506bb9b6a2c 

# however FETCH_HEAD shows something different 
> git rev-parse FETCH_HEAD 
37301df96597ac037f8e7e846fea6fc7df77bea5 

git pull esegue ancora il compito corretto. Tuttavia, l'esecuzione di git fetch; git merge FETCH_HEAD farà qualcosa di diverso dal FETCH_HEAD a un commit errato.

Esiste qualche impostazione o problema che potrebbe creare problemi con il comportamento di git fetch?

Answer 1

L'esecuzione di git fetch senza alcuna opzione consente di recuperare tutti i riferimenti nei telecomandi e di scriverli nel file .git/FETCH_HEAD. Il contenuto del file si presenta quando arrivavano o meno così:

37301df96597ac037f8e7e846fea6fc7df77bea5 branch 'master' of github.com:user/repo 
593539e8a98ba5980d4b645db3b0f506bb9b6a2c not-for-merge branch 'branchOne' of github.com:user/repo 

Quando si dispone di un file come questo sotto la directory .git, è possibile utilizzare come riferimento fino a quando la prima cosa in quel file è sia un 40 numero esadecimale del carattere o un numero esadecimale più breve che corrisponde effettivamente a un commit esistente.

# This file can be used as a reference 
> cat .git/MAGIC_HEAD 
deadbeefdeadbeefdeadbeefdeadbeefdeadbeef lorem ipsum 
the rest does not really matter 
refrigerator 

# And thus it will be interpreted by many git commands like this 
> git rev-parse MAGIC_HEAD 
deadbeefdeadbeefdeadbeefdeadbeefdeadbeef 

Sapendo questo possiamo vedere che dopo l'esecuzione git fetch il riferimento FETCH_HEAD risolverà a è tutto ciò che accade di essere in quella prima linea

# Assuming the already mentioned contents of .git/FETCH_HEAD 
> git rev-parse FETCH_HEAD 
37301df96597ac037f8e7e846fea6fc7df77bea5 

Sembra come l'ordine dei contenuti di .git/FETCH_HEAD non è garantito per contenere prima il riferimento per il ramo corrente.

Provandolo in diversi repository, sembra che in alcuni la prima riga sia sempre il ramo corrente, e quindi git fetch; git merge FETCH_HEAD funziona come previsto. Su altri repository, tuttavia, il contenuto di .git/FETCH_HEAD verrà ordinato in modo diverso e spesso la prima riga sarà un riferimento al commit remoto di un ramo diverso, rendendo quindi il riferimento FETCH_HEAD errato.

Perché comportarsi diversamente è un mistero per me.

Come soluzione, se git fetch remote_name branch_name viene utilizzato solo questo ramo specifico è recuperata e solo apparirà quella singola linea nel contenuto del .git/FETCH_HEAD, di rinvio FETCH_HEAD sempre corretta.

# Will only fetch branchone 
> git fetch origin branchone 

# FETCH_HEAD will contain only a single line 
> cat .git/FETCH_HEAD 
593539e8a98ba5980d4b645db3b0f506bb9b6a2c branch 'branchOne' of github.com:user/repo 

Answer 2

Basta provare a forzare la tua testa a puntare all'ultima commit/push che è stata fatta.

Utilizzare questo sul tuo repository GIT:

git reset --hard HEAD@{1} 

sperando che questo possa risolvere il problema, prendendo ad un punto in cui ha usato per funzionare perfettamente come prima.

Answer 3

Dopo aver eseguito git fetch (senza argomenti), FETCH_HEAD include solo un valido riferimento per la fusione (vale a dire non contrassegnato come non-per-merge) se la corrente sezione locale (vale a dire HEAD) è un ramo di monitoraggio.

La soluzione è quella di subordinare il ramo corrente un ramo di tracciamento (vedi How do you make an existing Git branch track a remote branch?) o specifica un telecomando e un ramo per andare a prendere (cioè git fetch origin branch