git-receive-pack - Online nel cloud

PROGRAMMA:

NOME

git-receive-pack - Ricevi ciò che viene inserito nel repository

SINOSSI

git-receive-pack

DESCRIZIONE

Invocato da git pacchetto di invio e aggiorna il repository con le informazioni fornite dal
fine remoto.

Questo comando di solito non viene invocato direttamente dall'utente finale. L'interfaccia utente per il protocollo è
sul canale git pacchetto di invio lato e la coppia di programmi è pensata per essere utilizzata per inviare aggiornamenti a
archivio remoto. Per le operazioni di trazione, vedere pacchetto-git-fetch(1).

Il comando consente la creazione e l'avanzamento rapido di sha1 refs (heads/tag) sul
estremità remota (in senso stretto, è la fine locale git-receive-pack corre, ma per l'utente
chi è seduto alla fine del pacchetto di invio, sta aggiornando il telecomando. Confuso?)

Ci sono altri esempi reali di utilizzo di hook di aggiornamento e post-aggiornamento trovati in
Directory documentazione/howto.

git-receive-pack onora l'opzione di configurazione riceve.denyNonFastForwards, che gli dice se
gli aggiornamenti a un riferimento dovrebbero essere negati se non sono in avanzamento rapido.

VERSIONI

Il repository in cui eseguire la sincronizzazione.

PRE-RICEZIONE HOOK

Prima che qualsiasi riferimento venga aggiornato, se il file $GIT_DIR/hooks/pre-receive esiste ed è eseguibile,
verrà invocato una volta senza parametri. L'input standard del gancio sarà una riga
per riferimento da aggiornare:

sha1-vecchio SP sha1-nuovo nome rif SP LF

Il valore di refname è relativo a $GIT_DIR; ad es. per la testata principale questo è
"refs/heads/master". I due valori sha1 prima di ogni refname sono i nomi degli oggetti per il
refname prima e dopo l'aggiornamento. I riferimenti da creare avranno sha1-old uguale a 0{40},
mentre i riferimenti da eliminare avranno sha1-new uguale a 0{40}, altrimenti sha1-old e
sha1-new dovrebbe essere oggetti validi nel repository.

Quando si accetta un push firmato (vedi git push(1)), il certificato push firmato è archiviato in a
blob e una variabile d'ambiente GIT_PUSH_CERT può essere consultata per il nome dell'oggetto. Vedere
la descrizione dell'hook post-ricezione per un esempio. Inoltre, il certificato è
verificato utilizzando GPG e il risultato viene esportato con le seguenti variabili di ambiente:

GIT_PUSH_CERT_SIGNER
Il nome e l'indirizzo e-mail del proprietario della chiave che ha firmato il push
certificato.

GIT_PUSH_CERT_KEY
L'ID chiave GPG della chiave che ha firmato il certificato push.

GIT_PUSH_CERT_STATUS
Lo stato della verifica GPG del certificato push, utilizzando lo stesso mnemonico di
utilizzato in %G? formato della famiglia di comandi git log (vedi git log(1)).

GIT_PUSH_CERT_NOnce
La stringa nonce che il processo ha chiesto al firmatario di includere nel certificato push. Se
questo non corrisponde al valore registrato sull'intestazione "nonce" nel certificato push,
può indicare che il certificato è valido e viene riprodotto da a
sessione "git push" separata.

GIT_PUSH_CERT_NONCE_STATUS

INDESIDERATA
"git push --signed" ha inviato un nonce quando non gli abbiamo chiesto di inviarne uno.

MISSING
"git push --signed" non ha inviato alcuna intestazione nonce.

BAD
"git push --signed" ha inviato un falso nonce.

OK
"git push --signed" ha inviato il nonce che gli abbiamo chiesto di inviare.

inclinazione
"git push --signed" ha inviato un nonce diverso da quello che gli abbiamo chiesto di inviare ora, ma
in una seduta precedente. Vedere la variabile di ambiente GIT_PUSH_CERT_NONCE_SLOP.

GIT_PUSH_CERT_NONCE_SLOP
"git push --signed" ha inviato un nonce diverso da quello che gli abbiamo chiesto di inviare ora, ma in a
sessione diversa il cui orario di inizio è diverso di tanti secondi dal
sessione corrente. Significativo solo quando GIT_PUSH_CERT_NONCE_STATUS dice SLOP. Leggi anche
sulla variabile riceve.certNonceSlop in git-config(1).

Questo hook viene chiamato prima che venga aggiornato qualsiasi refname e prima che vengano eseguiti controlli di avanzamento rapido
eseguita.

Se l'hook di pre-ricezione termina con uno stato di uscita diverso da zero, non verranno eseguiti aggiornamenti,
e nemmeno gli hook di aggiornamento, post-ricezione e post-aggiornamento verranno invocati. Questo può essere
utile per salvare rapidamente se l'aggiornamento non deve essere supportato.

AGGIORNAMENTO HOOK

Prima che ogni riferimento venga aggiornato, se il file $GIT_DIR/hooks/update esiste ed è eseguibile, è
invocato una volta per riferimento, con tre parametri:

$GIT_DIR/hooks/aggiorna refname sha1-vecchio sha1-nuovo

Il parametro refname è relativo a $GIT_DIR; ad es. per la testata principale questo è
"refs/heads/master". I due argomenti sha1 sono i nomi degli oggetti per il refname prima
e dopo l'aggiornamento. Nota che l'hook viene chiamato prima che il refname sia aggiornato, quindi
o sha1-old è 0{40} (il che significa che non esiste ancora tale riferimento), o dovrebbe corrispondere a ciò che è
registrato in refname.

L'hook dovrebbe uscire con uno stato diverso da zero se vuole impedire l'aggiornamento del ref denominato.
Altrimenti dovrebbe uscire con zero.

L'esecuzione riuscita (uno stato di uscita zero) di questo hook non garantisce che il ref lo farà
effettivamente essere aggiornato, è solo un prerequisito. Pertanto non è una buona idea inviare
avvisi (ad es. e-mail) da questo hook. Considera invece l'utilizzo dell'hook post-ricezione.

POST-RICEZIONE HOOK

Dopo che tutti i riferimenti sono stati aggiornati (o hanno tentato di essere aggiornati), se è stato effettuato un aggiornamento dei riferimenti
successo, e se il file $GIT_DIR/hooks/post-receive esiste ed è eseguibile, sarà
richiamato una volta senza parametri. L'input standard del gancio sarà una riga per ciascuno
aggiornato con successo ref:

sha1-vecchio SP sha1-nuovo nome rif SP LF

Il valore di refname è relativo a $GIT_DIR; ad es. per la testata principale questo è
"refs/heads/master". I due valori sha1 prima di ogni refname sono i nomi degli oggetti per il
refname prima e dopo l'aggiornamento. I riferimenti che sono stati creati avranno sha1-old uguale a
0{40}, mentre i riferimenti che sono stati eliminati avranno sha1-new uguale a 0{40}, altrimenti sha1-old
e sha1-new dovrebbero essere oggetti validi nel repository.

Le variabili di ambiente GIT_PUSH_CERT* possono essere ispezionate, proprio come nell'hook pre-ricezione,
dopo aver accettato un push firmato.

Utilizzando questo hook, è facile generare messaggi di posta che descrivono gli aggiornamenti al repository.
Questo script di esempio invia un messaggio di posta per riferimento elencando i commit inviati al
repository e registra i certificati push dei push firmati con firme valide in a
servizio di registrazione:

#!/bin/sh
# inviare per e-mail le informazioni sull'aggiornamento del commit.
mentre leggi ovale nval ref
do
if expr "$oval": '0*$' >/dev/null
poi
echo "Creato un nuovo riferimento, con i seguenti commit:"
git rev-list --pretty "$nval"
altro
echo "Nuovi commit:"
git rev-list --pretty "$nval" "^$oval"
fi |
mail -s "Modifiche al ref $ref" commit-list@mydomain
fatto
# certificato push firmato log, se presente
if test -n "${GIT_PUSH_CERT-}" && test ${GIT_PUSH_CERT_STATUS} = G
poi
(
echo nonce previsto è ${GIT_PUSH_NONCE}
git file cat blob ${GIT_PUSH_CERT}
) | mail -s "push certificato da $GIT_PUSH_CERT_SIGNER" push-log@miodominio
fi
esci da 0

Il codice di uscita da questa chiamata hook viene ignorato, tuttavia lo farà un codice di uscita diverso da zero
generare un messaggio di errore.

Nota che è possibile che refname non abbia sha1-new quando viene eseguito questo hook. questo può
si verificano facilmente se un altro utente modifica il riferimento dopo che è stato aggiornato da git-receive-pack,
ma prima che il gancio fosse in grado di valutarlo. Si raccomanda che gli hook si basino su sha1-new
piuttosto che il valore corrente di refname.

POST-AGGIORNAMENTO HOOK

Dopo tutte le altre elaborazioni, se almeno un riferimento è stato aggiornato e se
Il file $GIT_DIR/hooks/post-update esiste ed è eseguibile, quindi verrà chiamato post-update
con l'elenco dei riferimenti che sono stati aggiornati. Questo può essere usato per implementare qualsiasi repository
ampi compiti di pulizia.

Il codice di uscita da questa chiamata hook viene ignorato; l'unica cosa rimasta per
git-receive-pack da fare a quel punto è comunque uscire da se stesso.

Questo hook può essere utilizzato, ad esempio, per eseguire git update-server-info se il repository è
imballato ed è servito tramite un trasporto muto.

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

Usa git-receive-pack online utilizzando i servizi onworks.net