git-receive-pack - Online in de cloud

PROGRAMMA:

NAAM

git-receive-pack - Ontvang wat in de repository wordt gepusht

KORTE INHOUD

git-ontvangstpakket

PRODUCTBESCHRIJVING

Aangeroepen door git verzendpakket en werkt de repository bij met de informatie die wordt ingevoerd vanuit de
afgelegen einde.

Deze opdracht wordt meestal niet rechtstreeks door de eindgebruiker aangeroepen. De gebruikersinterface voor het protocol is
op de git verzendpakket kant, en het programmapaar is bedoeld om te worden gebruikt om updates naartoe te pushen
externe opslagplaats. Voor pull-bewerkingen, zie git-fetch-pack(1).

Met deze opdracht kunnen sha1-referenties (heads/tags) op de
externe uiteinde (strikt genomen is dit het lokale uiteinde git-ontvangstpakket draait, maar voor de gebruiker
wie er aan het einde van het verzendpakket zit, het werkt de afstandsbediening bij. Verward?)

Er zijn nog andere praktijkvoorbeelden van het gebruik van update- en post-update hooks te vinden in de
Documentatie/howto-directory.

git-ontvangstpakket respecteert de receiver.denyNonFastForwards configuratieoptie, die aangeeft of
updates van een ref moeten worden geweigerd als deze niet vooruitspoelen.

OPTIES

De opslagplaats waarmee moet worden gesynchroniseerd.

VOOR ONTVANGEN HOOK

Voordat een ref wordt bijgewerkt, als het bestand $GIT_DIR/hooks/pre-receive bestaat en uitvoerbaar is,
wordt één keer aangeroepen zonder parameters. De standaardinvoer van de hook is één regel
per ref die moet worden bijgewerkt:

sha1-oude SP sha1-nieuwe SP refnaam LF

De refname-waarde is relatief ten opzichte van $GIT_DIR; Voor het masterhoofd is dit bijvoorbeeld
"refs/hoofden/master". De twee sha1-waarden vóór elke refname zijn de objectnamen voor de
refname voor en na de update. De referenties die moeten worden gemaakt, hebben sha1-old gelijk aan 0{40},
terwijl refs die moeten worden verwijderd sha1-new gelijk hebben aan 0{40}, anders sha1-old en
sha1-new moeten geldige objecten in de repository zijn.

Bij het accepteren van een ondertekende push (zie git-push(1)), wordt het ondertekende pushcertificaat opgeslagen in een
blob en een omgevingsvariabele GIT_PUSH_CERT kunnen worden geraadpleegd voor de objectnaam ervan. Zien
de beschrijving van de post-ontvangsthaak als voorbeeld. Bovendien is het certificaat
geverifieerd met behulp van GPG en het resultaat wordt geëxporteerd met de volgende omgevingsvariabelen:

GIT_PUSH_CERT_SIGNER
De naam en het e-mailadres van de eigenaar van de sleutel die de push heeft ondertekend
certificaat.

GIT_PUSH_CERT_KEY
De GPG-sleutel-ID van de sleutel die het pushcertificaat heeft ondertekend.

GIT_PUSH_CERT_STATUS
De status van GPG-verificatie van het pushcertificaat, met hetzelfde geheugensteuntje als
gebruikt in %G? formaat van git log familie van commando's (zie git-log(1)).

GIT_PUSH_CERT_NONCE
De nonce-tekenreeks die het proces aan de ondertekenaar heeft gevraagd om op te nemen in het pushcertificaat. Als
dit komt niet overeen met de waarde die is vastgelegd in de header "nonce" in het pushcertificaat,
het kan erop wijzen dat het certificaat geldig is en wordt afgespeeld vanaf een
aparte "git push" sessie.

GIT_PUSH_CERT_NONCE_STATUS

ONGEVRAAGD
"git push --signed" stuurde een nonce terwijl we niet vroegen om er een te sturen.

MISSING
"git push --signed" heeft geen nonce header verzonden.

BAD
"git push --signed" stuurde een valse nonce.

OK
"git push --signed" stuurde de nonce die we vroegen te verzenden.

SLOP
"git push --signed" stuurde een nonce die anders was dan wat we hem nu vroegen te verzenden, maar
in een vorige sessie. Zie GIT_PUSH_CERT_NONCE_SLOP omgevingsvariabele.

GIT_PUSH_CERT_NONCE_SLOP
"git push --signed" stuurde een nonce die anders was dan wat we hem nu vroegen te verzenden, maar in een
een andere sessie waarvan de starttijd zoveel seconden verschilt van de
huidige sessie. Alleen zinvol als GIT_PUSH_CERT_NONCE_STATUS SLOP zegt. Lees ook
over de variabele receiver.certNonceSlop in git-config(1).

Deze hook wordt aangeroepen voordat een refname wordt bijgewerkt en voordat er fast-forward-controles plaatsvinden
uitgevoerd.

Als de pre-receive hook eindigt met een exit-status die niet nul is, worden er geen updates uitgevoerd.
en de update-, post-ontvangst- en post-update hooks zullen ook niet worden aangeroepen. Dit kan zijn
handig om snel uit de problemen te komen als de update niet ondersteund wil worden.

UPDATE HOOK

Voordat elke ref wordt bijgewerkt, als het bestand $GIT_DIR/hooks/update bestaat en uitvoerbaar is, is het
eenmaal per ref aangeroepen, met drie parameters:

$GIT_DIR/hooks/update refname sha1-oud sha1-nieuw

De parameter refname is relatief ten opzichte van $GIT_DIR; Voor het masterhoofd is dit bijvoorbeeld
"refs/hoofden/master". De twee sha1-argumenten zijn de objectnamen voor de refname ervoor
en na de update. Merk op dat de hook wordt aangeroepen voordat de refname wordt bijgewerkt, dus
óf sha1-old is 0{40} (wat betekent dat er nog geen dergelijke ref is), of het moet overeenkomen met wat
opgenomen in refnaam.

De hook zou moeten afsluiten met een niet-nul status als hij het bijwerken van de genoemde ref niet wil toestaan.
Anders zou het met nul moeten eindigen.

Een succesvolle uitvoering (een nul-exitstatus) van deze hook garandeert niet dat de scheidsrechter dat ook zal doen
daadwerkelijk worden bijgewerkt, is dit slechts een voorwaarde. Het is dus geen goed idee om te versturen
mededelingen (bijvoorbeeld e-mail) van deze hook. Overweeg om in plaats daarvan de post-ontvangsthaak te gebruiken.

NA ONTVANGST HOOK

Nadat alle refs waren bijgewerkt (of probeerden te worden bijgewerkt), als er een ref-update was
succesvol, en als het bestand $GIT_DIR/hooks/post-receive bestaat en uitvoerbaar is, zal het
eenmaal aangeroepen zonder parameters. De standaardinvoer van de hook is één regel voor elk
succesvol bijgewerkt ref:

sha1-oude SP sha1-nieuwe SP refnaam LF

De refname-waarde is relatief ten opzichte van $GIT_DIR; Voor het masterhoofd is dit bijvoorbeeld
"refs/hoofden/master". De twee sha1-waarden vóór elke refname zijn de objectnamen voor de
refname voor en na de update. Referenties die zijn gemaakt, hebben sha1-old gelijk aan
0{40}, terwijl refs die zijn verwijderd sha1-new gelijk hebben aan 0{40}, anders sha1-old
en sha1-new moeten geldige objecten in de repository zijn.

De GIT_PUSH_CERT* omgevingsvariabelen kunnen worden geïnspecteerd, net als bij pre-receive hook,
na het accepteren van een ondertekende push.

Met behulp van deze hook is het eenvoudig om e-mails te genereren waarin de updates voor de repository worden beschreven.
Dit voorbeeldscript verzendt één e-mailbericht per ref met een lijst van de commits die naar de zijn gepusht
repository, en logt de pushcertificaten van ondertekende pushes met goede handtekeningen naar een
logger-service:

#!/ Bin / sh
# mail out commit update-informatie.
terwijl lees ovale nval ref
do
if expr "$oval" : '0*$' >/dev/null
harte
echo "Een nieuwe ref gemaakt, met de volgende commits:"
git rev-list --mooi "$nval"
anders
echo "Nieuwe commits:"
git rev-list --mooi "$nval" "^$oval"
fi |
mail -s "Wijzigingen in ref $ref" commit-lijst@mijndomein
gedaan
# log ondertekend pushcertificaat, indien aanwezig
if test -n "${GIT_PUSH_CERT-}" && test ${GIT_PUSH_CERT_STATUS} = G
harte
(
verwachte echo nonce is ${GIT_PUSH_NONCE}
git cat-bestand blob ${GIT_PUSH_CERT}
) | mail -s "push certificaat van $GIT_PUSH_CERT_SIGNER" push-log@mijndomein
fi
verlaat 0

De exitcode van deze hook-aanroep wordt genegeerd, maar een exitcode die niet nul is, wel
een foutmelding genereren.

Merk op dat het mogelijk is dat refname geen sha1-new heeft wanneer deze hook draait. Dit kan
kan gemakkelijk voorkomen als een andere gebruiker de ref wijzigt nadat deze is bijgewerkt door git-ontvangstpakket,
maar voordat de haak het kon evalueren. Het wordt aanbevolen dat haken vertrouwen op sha1-new
in plaats van de huidige waarde van refname.

POST-UPDATE HOOK

Na alle andere verwerkingen, of ten minste één referentie is bijgewerkt, en of
Het bestand $GIT_DIR/hooks/post-update bestaat en is uitvoerbaar, waarna post-update wordt aangeroepen
met de lijst met refs die zijn bijgewerkt. Dit kan worden gebruikt om elke repository te implementeren
brede opruimwerkzaamheden.

De exitcode van deze hook-aanroep wordt genegeerd; het enige wat nog rest
git-ontvangstpakket wat je op dat moment doet, is hoe dan ook zichzelf verlaten.

Deze hook kan bijvoorbeeld gebruikt worden om git update-server-info uit te voeren als de repository dat wel is
verpakt en wordt geserveerd via een dom transport.

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

Gebruik git-receive-pack online met behulp van onworks.net-services