[git] Gałąź lokalna teoretycznie jest "ahed", mimo że status pokazuje jej aktualność

0

Mam dziwny problem z gitem. Tortoise git (klient okienkowy) pokazuje mi, że moja lokalna gałąź jest do przodu o 149 commitów w stosunku do remote. git status, git pull i git push stwierdzają aktualność gałęzi lokalnej z remotem. W momencie, gdy zrobię git reset --hard remote branch wskaźnik lokalny wycofuje mi się o te 149 commitów i mam stan sprzed 2 miesięcy. Wtedy Tortoise git stwierdza, że jestem up to date. Jeśli teraz zrobię git pull git z powrotem ściąga mi te 149 commitów z remota i znowu jestem ahed.
Dodatkowo phpStorm pokazuje mi, że wskaźnik remote i local są ustawione na tym samym commicie.

  1. Skąd takie zachowanie?
  2. Jak to uporządkować?
0

Sprawdź to robiąc to normalnie, a nie bazując na "domyslnym" ustawieniu w konfigu. Czyli git push origin nazwa_brancha_zdalnego zamiast git push, to samo tyczy się git pull - nie wiadomo co masz domyślnie tam wstawione, dlatego ja zawsze piszę dłuższe wersje pull/push bo wtedy wiem skąd i dokąd.

0

A jakie masz ustawione upstream dla tych gałęzi? Bo może Ci się to rozjechało?

0

@TurkucPodjadek: Próbowałem i tak i tak. Zawsze jest tak samo.
@hauleth Upstream jest ok > remotes/origin/master

Co ciekawe nie mam problemu z commitowaniem, mergowaniem i pushowaniem zmian. Mogę spokojnie dodawać kolejne zmiany, zrobić push i git wysyła tylke te zmiany, które właśnie zrobiłem. Gałąź remote też jest faktycznie aktualna, gdyż na innych maszynach wszystko pobiera się poprawnie.
Wygląda mi na jakiś problem z lokalnymi plikami gitowskimi, które się nie zaktualizowały z jakiegoś powodu. Próbowałem tez usunąć .git/index i zbudować go od zera, ale też to nic nie daje.
Obawiam się, że trzeba będzie klonować wszystko od zera jako jedyny pewny sposób.

1

Bardziej wygląda jak bug w Tortoise Git skoro git status zachowuje się normalnie. Zobacz, czy Tortoise nie tworzy jakiejś swojej struktury, którą używa do wyświetlania tych danych.

0

git fetch origin?
git rebase origin/master -i?

To drugie zapewne otworzy listę tych 150 commitów w edytorze. Zostaw tylko swoje, resztę wykasuj.

Upstream jest ok > remotes/origin/master

Ale upstream twojej branczy (jeśli to nie jest master) powinien być remotes/origin/nazwa_twojej_branczy a nie do mastera.
Spróbuj:
git push -u origin nazwa_twojej_branczy

1

Interaktywny rebase faktycznie wylistował mi te commity.
Finalnie jednak udało mi sie przy okazji dojść, co było problemem. Nie mam pojęcia w jaki sposób, ale przypadkiem musiałem utworzyć lokalną gałąź (albo raczej ustawić referencję), do której git trzymał referencje w refs/origin/master. Normalnie upstreamowa jest trzymana w refs/remotes/origin/master. Dodatkowo taka gałąź nie jest listowana nigdzie. Wobec czego te same nazwy miały dwa różne wskaźniki commitów przez co raz byłem ahead of a raz updated. Dopiero komenda rev-parse dała mi o tym znać. W związku z tym git update-ref -d refs/origin/master rozwiązało problem.

0
sabat24 napisał(a):

Interaktywny rebase faktycznie wylistował mi te commity.
Finalnie jednak udało mi sie przy okazji dojść, co było problemem. Nie mam pojęcia w jaki sposób, ale przypadkiem musiałem utworzyć lokalną gałąź (albo raczej ustawić referencję), do której git trzymał referencje w refs/origin/master.

Niestety, bardzo łatwo jest utworzyć branczę o nazwie "origin/master". To powinno być zabronione :-)

Zrobisz przez przypadek coś takiego git checkout -b origin/master i kłopoty gotowe...

Rozwiązaniem jest ją po prostu usunąć: git branch -D origin/master (tak, wiem, to wygląda strasznie).

1 użytkowników online, w tym zalogowanych: 0, gości: 1