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

Odpowiedz Nowy wątek
2019-04-17 09:47
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ć?

Pozostało 580 znaków

2019-04-17 10:02
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.

Pozostało 580 znaków

2019-04-17 10:19
0

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

Pozostało 580 znaków

2019-04-17 10:48
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.

Pozostało 580 znaków

2019-04-17 11:53
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.

Tak naprawdę problem zobaczyłem, gdy użyłem git reset --hard origin/master i mi usunęło lokalne commity. Wtedy włączyłem Tortoise, by łatwiej przejrzeć referencje i przy okazji zobaczyłem, jakieś dziwne wyniki. Porównywałem nawet pliki gita (poza samymi obiektami) między sklonowanym repo i tym starym i nie widzę nic szczególnie dziwnego. W każdym razie po sklonowaniu i skopiowaniu configów, działa poprawnie. Nie mam jednak pojęcia, skąd to się wzięło i jak to rozwiązać inaczej niż klonem. - sabat24 2019-04-17 13:07
@sabat24: polecam zrezygnować z Tortoise ;) Osobiście używam tylko i wyłącznie CLI i od bardzo bardzo dawna nie miałem większych problemów. - hauleth 2019-04-17 13:08
@hauleth: przez te lata nie nauczyłem się rozwiązywać konfliktów inaczej niż Tortoisem, więc po to własnie go trzymam :) problemy z gitem zrobiłem raczej sam bawiąc się hookami i coś, gdzieś poszło nie tak. Tortoisa podałem tylko jako przykład, że on wyśledził, iż coś jest na rzeczy, bo ani IDE ani git mnie o tym nie informowały. - sabat24 2019-04-17 19:12
@sabat24: po prostu zainstaluj sobie jakieś narzędzie do diffowania i ustaw odpowiedni mergetool w Gicie jeśli nie umiesz ręcznie. - hauleth 2019-04-18 09:54
@hauleth: tak mam też zrobione, a moim narzędziem jest właśnie Tortoise :) - sabat24 2019-04-18 14:33

Pozostało 580 znaków

2019-04-18 19:20
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

edytowany 5x, ostatnio: Azarien, 2019-04-18 19:25

Pozostało 580 znaków

2019-04-18 20:49
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.

edytowany 2x, ostatnio: sabat24, 2019-04-18 20:53

Pozostało 580 znaków

2019-04-20 17:57
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).

edytowany 2x, ostatnio: Azarien, 2019-04-20 17:58
Pokaż pozostałe 3 komentarze
No i jakby slash nie był dozwolony w nazwach branchy to remote/origin/master również nie byłby poprawną gałęzią, a Git niespecjalnie rozróżnia je od "zwykłych" branchy. - hauleth 2019-04-21 22:17
Co mnie obchodzą szczegóły implementacyjne Gita :-) - Azarien 2019-04-22 02:23
Tym, że gałęzie są tym samym, niezależnie czy są remote czy nie, więc jeśli zakazałbyś / w nazwach, to problem dalej by występował tylko z innym symbolem. - hauleth 2019-04-22 15:21
Gałąź lokalna O NAZWIE origin/master to nie to samo co "zdalna" gałąź master pochodząca z remote'a origin, którą również nazywa się origin/master. I w tym problem. - Azarien 2019-04-22 16:33
@Azarien: no tak, bo "zdalna" gałąź master pochodząca z remote'a origin to remote/origin/master. Jednak Git by ułatwić trochę pracę traktuje je "trochę wyjątkowo" - hauleth 2019-04-26 00:58

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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