git-receive-pack - Online în cloud

PROGRAM:

NUME

git-receive-pack - Primește ceea ce este împins în depozit

REZUMAT

git-receive-pack

DESCRIERE

Invocat de merge trimite-pachet și actualizează depozitul cu informațiile furnizate de la
capăt la distanță.

Această comandă nu este de obicei invocată direct de utilizatorul final. Interfața de utilizare pentru protocol este
pe merge trimite-pachet lateral, iar perechea de programe este menită să fie utilizată pentru a împinge actualizări către
depozit la distanță. Pentru operațiuni de tragere, vezi git-fetch-pack(1).

Comanda permite crearea și redirecționarea rapidă a referințelor sha1 (capete/etichete) pe
capăt la distanță (strict vorbind, este capătul local git-receive-pack rulează, dar utilizatorului
care stă la capătul pachetului de trimitere, actualizează telecomanda. Confuz?)

Există și alte exemple din lumea reală de utilizare a cârligelor de actualizare și post-actualizare găsite în
Director de documentație/howto.

git-receive-pack onorează opțiunea de configurare receive.denyNonFastForwards, care îi spune dacă
actualizările la o referință ar trebui refuzate dacă nu sunt înainte rapide.

OPŢIUNI

Depozitul în care să se sincronizeze.

PRE-PRIMIȚI HOOK

Înainte ca orice referință să fie actualizată, dacă fișierul $GIT_DIR/hooks/pre-receive există și este executabil, acesta
va fi invocat o dată fără parametri. Intrarea standard a cârligului va fi de o linie
pe ref pentru a fi actualizat:

sha1-vechiul SP sha1-nouul SP refname LF

Valoarea refname este relativă la $GIT_DIR; de exemplu, pentru șeful maestru asta este
„refs/heads/master”. Cele două valori sha1 înainte de fiecare refname sunt numele obiectelor pentru
refname înainte și după actualizare. Refurile care vor fi create vor avea sha1-old egal cu 0{40},
în timp ce referințele care urmează să fie șterse vor avea sha1-new egal cu 0{40}, în caz contrar sha1-old și
sha1-new ar trebui să fie obiecte valide în depozit.

Când se acceptă un push semnat (vezi git-push(1)), certificatul push semnat este stocat în a
blob și o variabilă de mediu GIT_PUSH_CERT pot fi consultate pentru numele obiectului său. Vedea
descrierea cârligului post-primire, de exemplu. În plus, certificatul este
verificat folosind GPG și rezultatul este exportat cu următoarele variabile de mediu:

GIT_PUSH_CERT_SIGNER
Numele și adresa de e-mail ale proprietarului cheii care a semnat push-ul
certificat.

GIT_PUSH_CERT_KEY
ID-ul cheii GPG al cheii care a semnat certificatul push.

GIT_PUSH_CERT_STATUS
Starea verificării GPG a certificatului push, folosind același mnemonic ca
folosit în %G? formatul familiei de comenzi git log (vezi git-log(1)).

GIT_PUSH_CERT_NONCE
Șirul nonce pe care procesul i-a cerut semnatarului să îl includă în certificatul push. Dacă
aceasta nu se potrivește cu valoarea înregistrată pe antetul „nonce” din certificatul push,
poate indica faptul că certificatul este unul valid, care este reluat de la a
sesiune separată „git push”.

GIT_PUSH_CERT_NONCE_STATUS

NESOLICITATE
„git push --signed” a trimis un nonce când nu i-am cerut să trimită unul.

LIPSĂ
„git push --signed” nu a trimis niciun antet nonce.

BAD
„git push --signed” a trimis un nonce fals.

OK
„git push --signed” a trimis nonce pe care i-am cerut să-l trimitem.

SLOP
„git push --signed” a trimis un nonce diferit de ceea ce i-am cerut să trimită acum, dar
într-o sesiune anterioară. Consultați variabila de mediu GIT_PUSH_CERT_NONCE_SLOP.

GIT_PUSH_CERT_NONCE_SLOP
„git push --signed” a trimis un nonce diferit de ceea ce i-am cerut să trimită acum, dar într-o
sesiune diferită a cărei oră de pornire este diferită cu atâtea secunde de
sesiunea curenta. Numai semnificativ atunci când GIT_PUSH_CERT_NONCE_STATUS spune SLOP. Citește și
despre variabila receive.certNonceSlop in git-config(1).

Acest cârlig este apelat înainte ca orice refname să fie actualizat și înainte ca orice verificare rapidă să fie efectuată
efectuat.

Dacă cârligul de pre-primire iese cu o stare de ieșire diferită de zero, nu vor fi efectuate actualizări,
iar nici cârligele de actualizare, post-primire și post-actualizare nu vor fi invocate. Acesta poate fi
util pentru a salva rapid dacă actualizarea nu va fi acceptată.

UPDATE HOOK

Înainte ca fiecare referință să fie actualizată, dacă fișierul $GIT_DIR/hooks/update există și este executabil, este
invocat o dată pe ref, cu trei parametri:

$GIT_DIR/hooks/update refname sha1-old sha1-new

Parametrul refname este relativ la $GIT_DIR; de exemplu, pentru șeful maestru asta este
„refs/heads/master”. Cele două argumente sha1 sunt numele obiectelor pentru refname-ul de dinainte
iar după actualizare. Rețineți că hook-ul este apelat înainte ca refname-ul să fie actualizat, deci
fie sha1-old este 0{40} (înseamnă că nu există încă o astfel de referință), fie ar trebui să se potrivească cu ceea ce este
înregistrat în refname.

Cârligul ar trebui să iasă cu o stare diferită de zero dacă dorește să interzică actualizarea referinței numite.
În caz contrar, ar trebui să iasă cu zero.

Execuția cu succes (o stare de ieșire zero) a acestui cârlig nu asigură ca ref
să fie actualizat, este doar o condiție prealabilă. Ca atare, nu este o idee bună să trimiteți
notificări (de exemplu, e-mail) de la acest cârlig. Luați în considerare utilizarea cârligului post-primire.

POST-PRIMIREA HOOK

După ce toate refurile au fost actualizate (sau au încercat să fie actualizate), dacă a fost vreo actualizare a referințelor
succes și dacă fișierul $GIT_DIR/hooks/post-receive există și este executabil, acesta va fi
invocat o dată fără parametri. Intrarea standard a cârligului va fi o linie pentru fiecare
ref actualizat cu succes:

sha1-vechiul SP sha1-nouul SP refname LF

Valoarea refname este relativă la $GIT_DIR; de exemplu, pentru șeful maestru asta este
„refs/heads/master”. Cele două valori sha1 înainte de fiecare refname sunt numele obiectelor pentru
refname înainte și după actualizare. Refurile care au fost create vor avea sha1-old egal cu
0{40}, în timp ce referințele care au fost șterse vor avea sha1-new egal cu 0{40}, în caz contrar sha1-old
și sha1-new ar trebui să fie obiecte valide în depozit.

Variabilele de mediu GIT_PUSH_CERT* pot fi inspectate, la fel ca în cârligul de pre-primire,
după ce a acceptat un impuls semnat.

Folosind acest cârlig, este ușor să generați e-mailuri care descriu actualizările pentru depozit.
Acest exemplu de script trimite un mesaj de e-mail pentru fiecare ref, listând commit-urile trimise către
depozit și înregistrează certificatele push ale push-urilor semnate cu semnături bune către a
serviciu logger:

#!/ Bin / sh
# trimiteți prin e-mail informațiile de actualizare de comitere.
în timp ce se citește oval nval ref
do
if expr "$oval": '0*$' >/dev/null
apoi
echo „S-a creat un nou ref, cu următoarele comiteri:”
git rev-list --destul de „$nval”
altfel
echo „Comite noi:”
git rev-list --pretty „$nval” „^$oval”
fi |
mail -s „Modificări la ref $ref” commit-list@mydomain
făcut
# certificat push semnat în jurnal, dacă există
dacă testul -n „${GIT_PUSH_CERT-}” și& testul ${GIT_PUSH_CERT_STATUS} = G
apoi
(
echo așteptat nonce este ${GIT_PUSH_NONCE}
blob git cat-file ${GIT_PUSH_CERT}
) | mail -s „push certificat de la $GIT_PUSH_CERT_SIGNER” push-log@domeniul meu
fi
iesirea 0

Codul de ieșire din această invocare a cârligului este ignorat, totuși un cod de ieșire diferit de zero
genera un mesaj de eroare.

Rețineți că este posibil ca refname să nu aibă sha1-new când rulează acest hook. Acesta poate
apare cu ușurință dacă un alt utilizator modifică referința după ce a fost actualizată de git-receive-pack,
dar înainte ca cârligul să-l poată evalua. Se recomandă ca cârligele să se bazeze pe sha1-new
mai degrabă decât valoarea curentă a refname.

POST-UPDATE HOOK

După toate celelalte procesări, dacă cel puțin un ref a fost actualizat și dacă
$GIT_DIR/hooks/fișier post-update există și este executabil, apoi va fi apelat post-update
cu lista de referințe care au fost actualizate. Acesta poate fi folosit pentru a implementa orice depozit
sarcini largi de curățare.

Codul de ieșire din această invocare de cârlig este ignorat; singurul lucru rămas pentru
git-receive-pack a face în acel moment înseamnă a ieși oricum.

Acest cârlig poate fi folosit, de exemplu, pentru a rula git update-server-info dacă depozitul este
ambalat și este servit printr-un transport prost.

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

Utilizați git-receive-pack online folosind serviciile onworks.net