git-receive-pack — Online w chmurze

PROGRAM:

IMIĘ

git-receive-pack - Odbierz to, co jest wepchnięte do repozytorium

STRESZCZENIE

pakiet-odbioru git

OPIS

Wywołany przez odrzutowiec wyślij paczkę i aktualizuje repozytorium o informacje pochodzące z
odległy koniec.

To polecenie zwykle nie jest wywoływane bezpośrednio przez użytkownika końcowego. Interfejs użytkownika protokołu to
na odrzutowiec wyślij paczkę strona, a para programów ma służyć do wypychania aktualizacji
zdalne repozytorium. Aby zapoznać się z operacjami ściągania, zobacz git-fetch-pack(1).

Polecenie pozwala na tworzenie i szybkie przekazywanie refów sha1 (nagłówków/tagów) na
odległy koniec (ściśle mówiąc, jest to koniec lokalny pakiet-odbioru git działa, ale dla użytkownika
który siedzi na końcu paczki wysyłającej, aktualizuje pilota. Zdezorientowany?)

Istnieją inne rzeczywiste przykłady użycia haków aktualizacji i post-aktualizacji, które można znaleźć w pliku
Katalog dokumentacji/howto.

pakiet-odbioru git honoruje opcję konfiguracyjną receive.denyNonFastForwards, która mówi, czy
aktualizacje referencji powinny zostać odrzucone, jeśli nie są one przewijane do przodu.

OPCJE

Repozytorium do synchronizacji.

PRZED ODBIOREM HOOK

Zanim jakikolwiek ref zostanie zaktualizowany, jeśli plik $GIT_DIR/hooks/pre-receive istnieje i jest wykonywalny, to
zostanie wywołany raz bez parametrów. Standardowym wejściem haka będzie jedna linia
na ref do aktualizacji:

sha1-stary SP sha1-nowy SP refname LF

Wartość refname jest względna względem $GIT_DIR; np. dla głowy głównej to jest
„refs/heads/master”. Dwie wartości sha1 przed każdą nazwą refname są nazwami obiektów dla
refname przed i po aktualizacji. Referencje, które mają zostać utworzone, będą miały sha1-old równe 0{40},
podczas gdy referencje do usunięcia będą miały sha1-new równe 0{40}, w przeciwnym razie sha1-old i
sha1-new powinny być prawidłowymi obiektami w repozytorium.

Podczas akceptowania podpisanego wypychania (zob git-push(1)), podpisany certyfikat wypychania jest przechowywany w pliku
blob i zmienną środowiskową GIT_PUSH_CERT można sprawdzić w celu uzyskania nazwy obiektu. Widzieć
przykładowy opis haka po odbiorze. Ponadto certyfikat jest
zweryfikowane za pomocą GPG, a wynik jest eksportowany z następującymi zmiennymi środowiskowymi:

GIT_PUSH_CERT_SIGNER
Nazwisko i adres e-mail właściciela klucza, który podpisał wypychanie
certyfikat.

GIT_PUSH_CERT_KEY
Identyfikator klucza GPG klucza, który podpisał certyfikat wypychania.

GIT_PUSH_CERT_STATUS
Status weryfikacji GPG certyfikatu push, przy użyciu tego samego mnemonika co
używany w %G? format rodziny poleceń git log (patrz git-log(1)).

GIT_PUSH_CERT_NONCE
Ciąg jednorazowy, o który proces poprosił osobę podpisującą w certyfikacie wypychanym. Jeśli
nie zgadza się to z wartością zapisaną w nagłówku „nonce” w certyfikacie push,
może to oznaczać, że certyfikat jest ważny i jest odtwarzany z a
oddzielna sesja „git push”.

GIT_PUSH_CERT_NONCE_STATUS

DOBROWOLNY
„git Push --signed” wysłało jednorazówkę, gdy nie poprosiliśmy go o wysłanie.

BRAKUJE
„git Push --signed” nie wysłało żadnego nagłówka jednorazowego.

BAD
„git Push --signed” wysłał fałszywy identyfikator jednorazowy.

OK
„git Push --signed” wysłało wartość jednorazową, o którą poprosiliśmy.

POMYJE
„git Push --signed” wysłało jednorazówkę inną niż ta, o którą poprosiliśmy teraz, ale
w poprzedniej sesji. Zobacz zmienną środowiskową GIT_PUSH_CERT_NONCE_SLOP.

GIT_PUSH_CERT_NONCE_SLOP
„git Push --signed” wysłało jednorazówkę inną niż ta, o którą poprosiliśmy teraz, ale w a
inna sesja, której czas rozpoczęcia różni się o tyle sekund od
obecna sesja. Ma znaczenie tylko wtedy, gdy GIT_PUSH_CERT_NONCE_STATUS mówi SLOP. Przeczytaj także
o zmiennej receive.certNonceSlop w git-config(1).

Ten hak jest wywoływany przed aktualizacją jakiejkolwiek nazwy refname i przed wszelkimi kontrolami szybkiego przewijania do przodu
wykonane.

Jeśli hak przed odbiorem zakończy działanie z niezerowym statusem wyjścia, żadne aktualizacje nie zostaną wykonane,
a haki aktualizacji, post-receive i post-update również nie zostaną wywołane. To może być
przydatne do szybkiego ratowania, jeśli aktualizacja nie ma być obsługiwana.

Aktualizacja HOOK

Zanim każdy ref zostanie zaktualizowany, jeśli plik $GIT_DIR/hooks/update istnieje i jest wykonywalny, to
wywoływana raz na ref, z trzema parametrami:

$GIT_DIR/hooks/update refname sha1-stary sha1-nowy

Parametr refname odnosi się do $GIT_DIR; np. dla głowy głównej to jest
„refs/heads/master”. Dwa argumenty sha1 są wcześniejszymi nazwami obiektów dla refname
i po aktualizacji. Zauważ, że hak jest wywoływany przed aktualizacją refname, więc
albo sha1-old wynosi 0{40} (co oznacza, że ​​nie ma jeszcze takiego odniesienia), albo powinien pasować do tego, co jest
zapisane w refname.

Hak powinien wyjść ze statusem niezerowym, jeśli chce uniemożliwić aktualizację nazwanego ref.
W przeciwnym razie powinien wyjść z zerem.

Pomyślne wykonanie (zerowy status wyjścia) tego haka nie gwarantuje, że ref will
faktycznie być aktualizowane, jest to tylko warunek wstępny. W związku z tym wysyłanie nie jest dobrym pomysłem
powiadomienia (np. e-mail) z tego haka. Zamiast tego rozważ użycie haka po odbiorze.

PO ODBIORZE HOOK

Po zaktualizowaniu wszystkich referencji (lub próbie aktualizacji), jeśli jakakolwiek aktualizacja ref
się powiodło, a jeśli plik $GIT_DIR/hooks/post-receive istnieje i jest wykonywalny, będzie
wywołany raz bez parametrów. Standardowym wejściem haka będzie jedna linia dla każdego
pomyślnie zaktualizowany ref:

sha1-stary SP sha1-nowy SP refname LF

Wartość refname jest względna względem $GIT_DIR; np. dla głowy głównej to jest
„refs/heads/master”. Dwie wartości sha1 przed każdą nazwą refname są nazwami obiektów dla
refname przed i po aktualizacji. Utworzone referencje będą miały sha1-old równe
0{40}, podczas gdy referencje, które zostały usunięte, będą miały sha1-new równe 0{40}, w przeciwnym razie sha1-old
i sha1-new powinny być prawidłowymi obiektami w repozytorium.

Zmienne środowiskowe GIT_PUSH_CERT* można sprawdzić, tak jak w haku przed odbiorem,
po zaakceptowaniu podpisanego wypychania.

Za pomocą tego haka łatwo jest generować maile opisujące aktualizacje repozytorium.
Ten przykładowy skrypt wysyła jedną wiadomość e-mail na każde odwołanie z listą zatwierdzeń wypchniętych do
repozytorium i rejestruje certyfikaty wypychania podpisanych wypychań z dobrymi podpisami w pliku a
obsługa rejestratora:

#!/ Bin / sh
# wyślij pocztą informacje o aktualizacji zatwierdzenia.
podczas czytania owalny nval ref
do
if expr "$oval" : '0*$' >/dev/null
następnie
echo "Utworzono nowy ref, z następującymi zatwierdzeniami:"
git rev-list --pretty "$nval"
więcej
echo "Nowe zatwierdzenia:"
git rev-list --pretty "$nval" "^$oval"
fi |
mail -s "Zmiany w ref $ref" commit-list@mydomain
zrobić
# dziennika podpisanego certyfikatu wypychania, jeśli istnieje
if test -n "${GIT_PUSH_CERT-}" && test ${GIT_PUSH_CERT_STATUS} = G
następnie
(
echo oczekiwany nonce to ${GIT_PUSH_NONCE}
obiekt blob z plikiem kota git ${GIT_PUSH_CERT}
) | mail -s „wypchnij certyfikat z $ GIT_PUSH_CERT_SIGNER” push-log@mydomain
fi
wyjście 0

Kod wyjścia z tego wywołania haka jest ignorowany, jednak niezerowy kod wyjścia tak
wygenerować komunikat o błędzie.

Zauważ, że możliwe jest, że refname nie będzie mieć sha1-new, gdy ten hak zostanie uruchomiony. To może
łatwo wystąpić, jeśli inny użytkownik zmodyfikuje ref po tym, jak został zaktualizowany przez pakiet-odbioru git,
ale zanim hak był w stanie to ocenić. Zaleca się, aby haki polegały na sha1-new
zamiast bieżącej wartości refname.

PO AKTUALIZACJI HOOK

Po wszystkich innych procesach, jeśli co najmniej jedno odwołanie zostało zaktualizowane i jeśli
Plik $GIT_DIR/hooks/post-update istnieje i jest wykonywalny, wtedy zostanie wywołana post-update
z listą referencji, które zostały zaktualizowane. Można to wykorzystać do zaimplementowania dowolnego repozytorium
szerokie zadania sprzątania.

Kod wyjścia z tego wywołania haka jest ignorowany; jedyne co zostało
pakiet-odbioru git zrobić w tym momencie, to i tak wyjść z siebie.

Tego haka można użyć na przykład do uruchomienia git update-server-info, jeśli repozytorium jest
zapakowane i podawane przez głupi transport.

#!/ Bin / sh
exec git update-server-info

Użyj git-receive-pack online, korzystając z usług onworks.net