Dlaczego używa się git push gerrit HEAD: refs / for / master zamiast git push origin master


148

Właśnie zacząłem używać Gerrit i chcę wiedzieć, dlaczego musimy to zrobić git push gerrit HEAD:refs/for/masterzamiast robićgit push origin master

Jeśli tak się stanie, pojawi git push origin mastersię komunikat o błędzie! [remote rejected] master -> master (prohibited by Gerrit)

Odpowiedzi:


259

Dokumentacja dla Gerrit, w szczególności sekcja „Wypychanie zmian” , wyjaśnia, że ​​wypychasz do „magicznego odniesienia refs/for/'branch'za pomocą dowolnego narzędzia klienta Git”.

Poniższy obraz pochodzi z Intro to Gerrit . Kiedy naciskasz na Gerrita, robisz git push gerrit HEAD:refs/for/<BRANCH>. Spowoduje to przeniesienie zmian do obszaru przejściowego (na diagramie „Oczekujące zmiany”). Gerrit tak naprawdę nie ma gałęzi o nazwie <BRANCH>; to leży po stronie klienta git.

Wewnętrznie Gerrit ma własną implementację dla stosów Git i SSH. Pozwala to na dostarczenie „magicznych” odniesień refs/for/<BRANCH>.

Po odebraniu żądania wypychania w celu utworzenia odwołania w jednej z tych przestrzeni nazw, Gerrit wykonuje własną logikę aktualizacji bazy danych, a następnie okłamuje klienta o wyniku operacji. Pomyślny wynik powoduje, że klient wierzy, że Gerrit stworzył odniesienie, ale w rzeczywistości Gerrit w ogóle go nie utworzył. [ Link - Gerrit, „Gritty Details” ].

Przepływ pracy Gerrit

Po udanej łatce (tj. Poprawka została przesłana do Gerrit, [umieszczona w strefie tymczasowej "Oczekujących zmian"], przejrzana i przejrzana), Gerrit wypycha zmianę z "Oczekujących zmian" do " Autorytatywne repozytorium ”, obliczające, do której gałęzi należy go wepchnąć, na podstawie magii, jaką zrobił, gdy popchnąłeś refs/for/<BRANCH>. W ten sposób pomyślnie sprawdzone poprawki można pobrać bezpośrednio z odpowiednich gałęzi Authoritative Repository.


Z ciekawości, co tak naprawdę się stanie, jeśli zrobisz coś takiego jak „git push origin”? Spróbowałem tego i nigdzie nie widzę zmiany, stąd pytanie. Ale oczywiście istnieje w moim dzienniku lokalnym.

1
@Pintolaranja Zrobiłem to samo przypadkowo. Masz rację, Gerrit „radzi sobie” z taką sytuacją, ale nie powoduje to żadnej zmiany. Więc w rzeczywistości w ogóle go nie obsługuje. Co mnie naprawdę wkurza, bo to jest naprawdę głupie. Po co pozwalać użytkownikowi na popełnienie czegoś, czego Gerrit nie jest w stanie właściwie obsłużyć?
— trejder

1
@gregb Yes. Strzałki wskazują źródło i cel polecenia, a nie wynikający z niego przepływ danych. np. deweloper 1 wysyła pobieranie do autorytatywnego repozytorium, a nie na odwrót
— Gareth

5
@trejder Pozwala na to, ponieważ Gerrit umożliwia skonfigurowanie niektórych kont w celu ominięcia recenzji. Pchając do gałęzi domyślnej, skutecznie mówisz „Chcę scalić tę zmianę bez recenzji”. Jeśli nie możesz tego zrobić, push się nie powiedzie.
— Hounshell,

4
Lub nie możesz użyć gerrit i całkowicie uniknąć tego przezabawnego bałaganu.
— C Johnson

57

Aby uniknąć konieczności pełnego określenia polecenia git push, możesz alternatywnie zmodyfikować plik konfiguracyjny git:

[remote "gerrit"]
    url = https://your.gerrit.repo:44444/repo
    fetch = +refs/heads/master:refs/remotes/origin/master
    push = refs/heads/master:refs/for/master

Teraz możesz po prostu:

git fetch gerrit
git push gerrit

Tak jest według Gerrita


1
+1 ode mnie! O wiele przyjemniej jest mieć to zakodowane na stałe, remote.origin.pushzamiast wpisywać / wklejać za każdym razem!
— DaoWen

7
@SeanMurphy Możesz uczynić to bardziej ogólnym, zastępując instancje „master” przez „*”, tak aby działało również coś takiego jak „git push gerrit TopicBranch”.
— David Doria,

Ponadto, jeśli gerrit jest Twoim jedynym pilotem, nie musisz go wcale określać. Po prostu robię git fetchi git pushze wspomnianą wyżej konfiguracją @DavidDoria.
— bernk,

push = refs / heads / *: refs / for / * dotyczy wszystkich gałęzi
— Victor Choy,

Naprawdę musisz użyć gałęzi upstream, a nie obecnej. Zwykle mam kilkanaście zmian zachodzących równolegle, więc użycie jednej gałęzi po prostu nie działa.
— Christian Goetze
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.