2012-07-13 8 views
7

Mam lokalne repozytorium, które pobiera z odległego. Uruchamianie git pull jak również git fetch; git merge FETCH_HEAD używany do wykonywania dokładnie takie samo działanie, jak oczekuje się od description of git pull:Odwołanie FETCH_HEAD nie aktualizuje się poprawnie po "git fetch"

OPIS

Wprowadza zmiany od zdalnego repozytorium do bieżącego oddziału. W trybie domyślnym, git pull jest skrótem dla pobierania git, a następnie git merge FETCH_HEAD.

Obecnie nieoczekiwanie, działa git fetch zatrzymał aktualizowanie odniesienie FETCH_HEAD poprawnie. FETCH_HEAD jest teraz przyklejony do starego zatwierdzenia. Uruchamianie git fetch powoduje pobranie wszystkich zmian do zdalnie śledzonych gałęzi, ale FETCH_HEAD pozostaje niezmieniony niezależnie od gałęzi, w której jest uruchamiany.

# 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 nadal wykonuje poprawne zadanie. Jednak uruchomienie git fetch; git merge FETCH_HEAD spowoduje coś innego, ponieważ FETCH_HEAD wskazuje na nieprawidłowe zatwierdzenie.

Czy istnieją jakieś ustawienia lub problemy, które mogą powodować problemy z zachowaniem git fetch?

Odpowiedz

7

Uruchamianie git fetch bez żadnych opcji spowoduje pobranie wszystkich odniesień w pilotach zdalnego sterowania i zapisanie ich w pliku .git/FETCH_HEAD. Zawartość pliku przeważnie wygląda mniej więcej tak:

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

Gdy masz plik takiego w katalogu .git, można go używać jako odniesienie, o ile pierwsza rzecz w tym pliku jest albo 40 liczba heksadecymalna lub krótszy numer heksadecymalny, który faktycznie pasuje do istniejącego zatwierdzenia.

# 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 

Wiedząc o tym możemy zobaczyć, że po uruchomieniu git fetch odniesienie FETCH_HEAD będzie rozwiązać, aby to, co dzieje się w tej pierwszej linii

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

wydaje się zlecenia zawartości .git/FETCH_HEAD nie jest gwarantowana najpierw zawierać referencję dla bieżącego oddziału.

Próbując go w różnych repozytoriach, wydaje się, że w niektórych pierwszych wierszach zawsze jest obecna gałąź, a zatem git fetch; git merge FETCH_HEAD działa zgodnie z oczekiwaniami. Jednak w innych repozytoriach zawartość .git/FETCH_HEAD będzie inaczej zamawiana i często pierwsza linia będzie odwołaniem do zdalnego zatwierdzenia innego oddziału, co spowoduje, że odniesienie FETCH_HEAD będzie nieprawidłowe.

Dlaczego zachowuje się inaczej, jest dla mnie zagadką.

Jako rozwiązanie, jeśli git fetch remote_name branch_name służy tylko ten konkretny oddział jest naciągane i pojawi się tylko jeden wiersz w treści .git/FETCH_HEAD, czyniąc odniesienia FETCH_HEAD zawsze poprawne.

# 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 
0

Po prostu spróbuj zmusić swoją głowę do wskazania ostatniego zatwierdzenia/pchnięcia, które zostało zrobione.

Użyj tego na swoim repozytorium GIT:

git reset --hard [email protected]{1} 

Licząc to może rozwiązać problem, biorąc to do punktu, w którym dawniej działa idealnie jak wcześniej.

+0

Niestety nie. Nawet resetowanie repozytorium bardzo stare wersje zmienia nic w zachowanie 'git fetch' i' FETCH_HEAD'. – LopSae

+0

Inną rzeczą, którą możesz spróbować, jest usunięcie całego lokalnego repozytorium i sklonowanie go ponownie.Jeśli nie, pomogę ci dalej.Spróbuję ocenić, co jest z tobą nie tak Lokalne repozytorium .. – aliasgar

+0

W nowym repozytorium zachowanie jest takie samo. Zatwierdzenie, do którego odnosi się "FETCH_HEAD", jest pierwszym, które pojawia się w pliku '.git/FETCH_HEAD'. Odczytanie go wydaje się być zamierzonym zachowaniem, ale Wciąż mam wątpliwości co do czego y wcześniej robiłeś 'git fetch; git merge FETCH_HEAD' działało doskonale w każdym oddziale. – LopSae

0

Po uruchomieniu git fetch (bez argumentów), FETCH_HEAD obejmie tylko odniesienie ważny dla łączenia (to znaczy nie oznaczone jako not-for-scaleniu), jeśli aktualny miejscowy oddział (tj HEAD) jest gałęzią śledzenia.

Rozwiązaniem jest albo uczynić prądowym oddział śledzenia (patrz How do you make an existing Git branch track a remote branch?) lub określić zdalny i oddział do pobrania (tj git fetch origin branch

+0

Oddziały, nad którymi pracowałem, gdzie wszystkie oddziały już śledzą oddział zdalny. Po zwróceniu mojej uwagi na to pytanie ponownie zmieniłem odpowiedź, aby lepiej wyjaśnić, dlaczego odwołanie do 'FETCH_HEAD' nie aktualizuje się poprawnie. Może ma to jakieś znaczenie, o czym wspomniałeś, a pierwsza linia w '.git/FETCH_HEAD' jest gwarantowana tylko w pewnych innych okolicznościach, o których nie wiem. – LopSae

Powiązane problemy