Svenska ▾ Topics ▾ Latest version ▾ git-receive-pack last updated in 2.50.0

NAMN

git-receive-pack - Ta emot det som skickas till kodförrådet

SYNOPSIS

git receive-pack <git-kat>

BESKRIVNING

Anropas av git send-pack och uppdaterar förvaret med informationen som matas från fjärränden.

Detta kommando anropas vanligtvis inte direkt av slutanvändaren. Användargränssnittet för protokollet finns på git send-pack-sidan, och programparet är avsett att användas för att skicka uppdateringar till ett fjärrarkiv. För pull-operationer, se git-fetch-pack[1].

Kommandot möjliggör skapande och snabbspolning av sha1-referenser (huvuden/taggar) på fjärrsidan (strikt taget är det den lokala änden som git-receive-pack körs, men för användaren som sitter i send-pack-änden uppdaterar det fjärrsidan. Förvirrad?)

Det finns andra verkliga exempel på hur man använder uppdaterings- och post-uppdaterings-krokar i katalogen Dokumentation/howto.

git-receive-pack accepterar konfigurationsalternativet receive.denyNonFastForwards, vilket anger om uppdateringar till en referens ska nekas om de inte är snabbspolningar framåt.

Ett antal andra receive.*-konfigurationsalternativ finns tillgängliga för att justera dess beteende, se git-config[1].

ALTERNATIV

<git-kat>

Förvaret att synkronisera till.

--http-backend-info-refs

Används av git-http-backend[1] för att hantera $GIT_URL/info/refs?service=git-receive-pack-förfrågningar. Se --http-backend-info-refs i git-upload-pack[1].

--skip-connectivity-check

Kringgår anslutningskontrollerna som validerar förekomsten av alla objekt i den transitiva stängningen av nåbara objekt. Det här alternativet är avsett för serveroperatörer som vill implementera sin egen objektanslutningsvalidering utanför Git. Detta är användbart i sådana fall där serversidan känner till ytterligare information om hur Git används och därmed kan förlita sig på vissa garantier för att mer effektivt beräkna objektanslutning som Git självt inte kan ge. Användning av det här alternativet utan en tillförlitlig extern mekanism för att säkerställa fullständig nåbar objektanslutning riskerar att korrumpera arkivet och bör inte användas i det allmänna fallet.

FÖRMOTTAGNINGSKROK

Innan någon referens uppdateras, om filen $GIT_DIR/hooks/pre-receive finns och är körbar, kommer den att anropas en gång utan parametrar. Standardinmatningen för kroken kommer att vara en rad per referens som ska uppdateras:

sha1-gammal SP sha1-ny SP refnamn LF

Refnamnsvärdet är relativt till $GIT_DIR; t.ex. för master-huvidet är detta "refs/heads/master". De två sha1-värdena före varje refnamn är objektnamnen för refnamnet före och efter uppdateringen. Referenser som ska skapas kommer att ha sha1-gammal lika med 0{40}, medan referenser som ska raderas kommer att ha sha1-ny lika med 0{40}, annars bör sha1-gammal och sha1-ny vara giltiga objekt i arkivet.

När en signerad push accepteras (se git-push[1]) lagras det signerade push-certifikatet i en blob och en miljövariabel GIT_PUSH_CERT kan konsulteras för dess objektnamn. Se beskrivningen av post-receive krok för ett exempel. Dessutom verifieras certifikatet med GPG och resultatet exporteras med följande miljövariabler:

GIT_PUSH_CERT_SIGNER

Namnet och e-postadressen till ägaren av nyckeln som signerade push-certifikatet.

GIT_PUSH_CERT_KEY

GPG-nyckel-ID:t för nyckeln som signerade push-certifikatet.

GIT_PUSH_CERT_STATUS

Status för GPG-verifiering av push-certifikatet, med samma mnemoniska kod som används i %G?-formatet för git log-kommandofamiljen (se git-log[1]).

GIT_PUSH_CERT_NONCE

Nonce-strängen som processen bad signeraren att inkludera i push-certifikatet. Om detta inte matchar värdet som registrerats i "nonce"-huvudet (engångstal) i push-certifikatet kan det tyda på att certifikatet är giltigt och spelas upp från en separat "git push"-session.

GIT_PUSH_CERT_NONCE_STATUS
UNSOLICITED

"git push --signed" skickade ett engångstal-meddelande när vi inte bad den att skicka ett.

MISSING

"git push --signed" skickade inget nonce-huvud.

BAD

"git push --signed" skickade ett falskt engångstal.

OK

"git push --signed" skickade engångstal vi bad den att skicka.

SLOP

"git push --signed" skickade en annan engångstal än vad vi bad den skicka nu, men i en tidigare session. Se miljövariabeln GIT_PUSH_CERT_NONCE_SLOP.

GIT_PUSH_CERT_NONCE_SLOP

"git push --signed" skickade en engångstal som skiljer sig från vad vi bad den att skicka nu, men i en annan session vars starttid skiljer sig med så här många sekunder från den aktuella sessionen. Endast meningsfullt när GIT_PUSH_CERT_NONCE_STATUS säger SLOP. Läs även om variabeln receive.certNonceSlop i git-config[1].

Denna krok anropas innan något refname uppdateras och innan några snabbspolningskontroller utförs.

Om pre-receive-krokenen avslutas med en avslutningsstatus som inte är noll kommer inga uppdateringar att utföras, och krokarna update, post-receive och post-update kommer inte heller att anropas. Detta kan vara användbart för att snabbt kunna lösa ut om uppdateringen inte ska stödjas.

Se anvisningarna om karantänmiljön nedan.

UPPDATERINGS KROK

Innan varje referens uppdateras, om filen $GIT_DIR/hooks/update finns och är körbar, anropas den en gång per referens, med tre parametrar:

$GIT_DIR/hooks/update refnamn sha1-gammal sha1-ny

Parametern refnamn är relativ till $GIT_DIR; t.ex. för master-huvudet är detta "refs/heads/master". De två sha1-argumenten är objektnamnen för refnamen före och efter uppdateringen. Observera att kroken anropas innan refnamen uppdateras, så antingen är sha1-gammal 0{40} (vilket betyder att det inte finns någon sådan ref ännu), eller så bör den matcha det som är registrerat i refname.

Kroken ska avslutas med status som inte är noll om den vill förhindra uppdatering av den namngivna referensen. Annars ska den avslutas med noll.

Lyckad exekvering (noll exitstatus) av denna krok garanterar inte att referensen faktiskt kommer att uppdateras, det är bara en förutsättning. Därför är det inte en bra idé att skicka meddelanden (t.ex. e-post) från denna krok. Överväg att använda post-receive-kroken istället.

EFTER-MOTTAGNINGS KROK

Efter att alla referenser har uppdaterats (eller försökts uppdateras), om någon referensuppdatering lyckades, och om filen $GIT_DIR/hooks/post-receive finns och är körbar, kommer den att anropas en gång utan parametrar. Standardinmatningen för kroken kommer att vara en rad för varje framgångsrikt uppdaterad referens:

sha1-gammal SP sha1-ny SP refnamn LF

Refnamnsvärdet är relativt till $GIT_DIR; t.ex. för master-huvudet är detta "refs/heads/master". De två sha1-värdena före varje refnamn är objektnamnen för refnamnet före och efter uppdateringen. Referenser som skapades kommer att ha sha1-gammal lika med 0{40}, medan referenser som raderades kommer att ha sha1-ny lika med 0{40}, annars bör sha1-gammal och sha1-ny vara giltiga objekt i fövaret.

Miljövariablerna GIT_PUSH_CERT* kan inspekteras, precis som i pre-receive kroken, efter att en signerad push har accepterats.

Med hjälp av denna krok är det enkelt att generera e-postmeddelanden som beskriver uppdateringarna till kodförrådet. Detta exempelskript skickar ett e-postmeddelande per referens som listar de incheckningar som pushas till kodförrådet och loggar push-certifikaten för signerade pushes med godkända signaturer till en loggtjänst:

#!/bin/sh
# skicka ut information om uppdatering av commit.
while read oval nval ref
do
	if expr "$oval" : '0*$' >/dev/null
	then
		echo "Skapade en ny ref, med följande incheckningar:"
		git rev-list --pretty "$nval"
	else
		echo "Nya incheckningar:"
		git rev-list --pretty "$nval" "^$oval"
	fi |
	mail -s "Ändringar i ref $ref" inchecknings-lista@mindomän
done
# logga signerat push-certifikat, om något
if test -n "${GIT_PUSH_CERT-}" && test ${GIT_PUSH_CERT_STATUS} = G
then
	(
		echo expected nonce is ${GIT_PUSH_NONCE}
		git cat-file blob ${GIT_PUSH_CERT}
	) | mail -s "push-certifikat från $GIT_PUSH_CERT_SIGNER" push-logg@mindomän
fi
exit 0

Avslutningskoden från detta krok-anrop ignoreras, men en avslutningskod som inte är noll genererar ett felmeddelande.

Observera att det är möjligt för refnamn att inte ha sha1-ny när denna krok körs. Detta kan lätt inträffa om en annan användare ändrar refen efter att den uppdaterades av git-receive-pack, men innan kroken kunde utvärdera den. Det rekommenderas att krokar förlitar sig på sha1-ny snarare än det aktuella värdet för refnamn.

EFTER-UPPDATERINGS KROK

Efter all annan bearbetning, om minst en referens uppdaterades, och om filen $GIT_DIR/hooks/post-update finns och är körbar, kommer post-update att anropas med listan över referenser som har uppdaterats. Detta kan användas för att implementera alla typer av rensningsuppgifter för hela arkivet.

Avslutningskoden från detta krok-anrop ignoreras; det enda som återstår för git-receive-pack att göra vid den tidpunkten är att avsluta sig själv ändå.

Denna krok kan till exempel användas för att köra git update-server-info om kodförrådet är packat och hanteras via en dum transport.

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

KARANTÄNS-MILJÖ

När receive-pack tar emot objekt placeras de i en tillfällig "karantän"-katalog i $GIT_DIR/objects-katalogen och migreras till huvudobjektlagringen först efter att pre-receive-kroken har slutförts. Om push-funktionen misslyckas innan dess tas den tillfälliga katalogen bort helt.

Detta har några effekter och förbehåll som är synliga för användaren:

  1. Push-filer som misslyckas på grund av problem med det inkommande paketet, saknade objekt eller på grund av pre-receive-kroken kommer inte att lämna några data på disken. Detta är vanligtvis bra för att förhindra att upprepade misslyckade push-filer fyller upp din disk, men kan göra felsökning mer utmanande.

  2. Alla objekt som skapas av pre-receive-kroken skapas i karantäns-katalogen (och migreras endast om det lyckas).

  3. pre-receive-kroken FÅR INTE uppdatera några referenser för att peka på objekt i karantän. Andra program som använder arkivet kommer inte att kunna se objekten (och om pre-receive-kroken misslyckas kommer dessa referenser att bli skadade). Av säkerhetsskäl avvisas alla referensuppdateringar inifrån pre-receive automatiskt.

SE ÄVEN

git-send-pack[1], gitnamespaces[7]

GIT

En del av git[1]-sviten