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.