git-receive-pack - En ligne dans le Cloud

PROGRAMME:

Nom

git-receive-pack - Recevoir ce qui est poussé dans le référentiel

SYNOPSIS

git-recevoir-pack

DESCRIPTION

Invoqué par jet envoyer-pack et met à jour le référentiel avec les informations fournies par le
extrémité distante.

Cette commande n'est généralement pas invoquée directement par l'utilisateur final. L'interface utilisateur du protocole est
sur le jet envoyer-pack côté, et la paire de programmes est destinée à être utilisée pour pousser les mises à jour vers
référentiel distant. Pour les opérations d'extraction, voir git-fetch-pack (1).

La commande permet la création et l'avance rapide de sha1 refs (heads/tags) sur le
extrémité distante (à proprement parler, c'est l'extrémité locale git-recevoir-pack s'exécute, mais à l'utilisateur
qui est assis à l'extrémité du pack d'envoi, il met à jour la télécommande. Confus?)

Il existe d'autres exemples concrets d'utilisation de crochets de mise à jour et de post-mise à jour trouvés dans le
Répertoire documentation/howto.

git-recevoir-pack honore l'option de configuration receive.denyNonFastForwards, qui lui indique si
les mises à jour d'une référence doivent être refusées si elles ne sont pas des avances rapides.

OPTIONS

Le référentiel dans lequel synchroniser.

PRE-RECEPTION CROCHET

Avant qu'une référence ne soit mise à jour, si le fichier $GIT_DIR/hooks/pre-receive existe et est exécutable, il
sera invoqué une fois sans paramètre. L'entrée standard du crochet sera une ligne
par réf à mettre à jour :

sha1-ancien SP sha1-nouveau SP refname LF

La valeur du nom de référence est relative à $GIT_DIR ; par exemple pour la tête principale c'est
"refs/heads/master". Les deux valeurs sha1 avant chaque refname sont les noms d'objet pour le
refname avant et après la mise à jour. Les références à créer auront sha1-old égal à 0{40},
tandis que les références à supprimer auront sha1-new égal à 0{40}, sinon sha1-old et
sha1-new doit être des objets valides dans le référentiel.

Lors de l'acceptation d'un push signé (voir git-push(1)), le certificat push signé est stocké dans un
blob et une variable d'environnement GIT_PUSH_CERT peuvent être consultés pour son nom d'objet. Voir
la description du crochet post-réception pour un exemple. De plus, le certificat est
vérifié à l'aide de GPG et le résultat est exporté avec les variables d'environnement suivantes :

GIT_PUSH_CERT_SIGNER
Le nom et l'adresse e-mail du propriétaire de la clé qui a signé le push
certificat.

GIT_PUSH_CERT_KEY
L'ID de clé GPG de la clé qui a signé le certificat push.

GIT_PUSH_CERT_STATUS
Le statut de vérification GPG du certificat push, utilisant le même mnémonique que
utilisé dans %G ? format de la famille de commandes git log (voir journal git(1)).

GIT_PUSH_CERT_NONCE
La chaîne de nonce que le processus a demandé au signataire d'inclure dans le certificat push. Si
cela ne correspond pas à la valeur enregistrée sur l'entête "nonce" dans le certificat push,
cela peut indiquer que le certificat est valide et qu'il est rejoué à partir d'un
session "git push" séparée.

GIT_PUSH_CERT_NONCE_STATUS

NON SOLLICITÉ
"git push --signed" a envoyé un nonce alors que nous ne lui avons pas demandé d'en envoyer un.

DISPARU
"git push --signed" n'a envoyé aucun en-tête nonce.

BAD
"git push --signed" a envoyé un faux nonce.

OK
"git push --signed" a envoyé le nonce que nous lui avons demandé d'envoyer.

PENTE
"git push --signed" a envoyé un nonce différent de ce que nous lui avons demandé d'envoyer maintenant, mais
lors d'une session précédente. Voir la variable d'environnement GIT_PUSH_CERT_NONCE_SLOP.

GIT_PUSH_CERT_NONCE_SLOP
"git push --signed" a envoyé un nonce différent de ce que nous lui avons demandé d'envoyer maintenant, mais dans un
session différente dont l'heure de début est différente de ce nombre de secondes de la
session actuelle. Significatif uniquement lorsque GIT_PUSH_CERT_NONCE_STATUS indique SLOP. Lire aussi
à propos de la variable receive.certNonceSlop dans git-config (1).

Ce hook est appelé avant la mise à jour de tout nom de référence et avant toute vérification rapide
effectué.

Si le hook de pré-réception se termine avec un état de sortie différent de zéro, aucune mise à jour ne sera effectuée,
et les hooks de mise à jour, de post-réception et de post-mise à jour ne seront pas invoqués non plus. Cela peut être
utile pour renflouer rapidement si la mise à jour ne doit pas être prise en charge.

MISE À JOUR CROCHET

Avant que chaque référence ne soit mise à jour, si le fichier $GIT_DIR/hooks/update existe et est exécutable, il est
invoqué une fois par ref, avec trois paramètres :

$GIT_DIR/hooks/update refname sha1-ancien sha1-nouveau

Le paramètre refname est relatif à $GIT_DIR ; par exemple pour la tête principale c'est
"refs/heads/master". Les deux arguments sha1 sont les noms d'objet pour le refname avant
et après la mise à jour. Notez que le hook est appelé avant que le nom de référence ne soit mis à jour, donc
soit sha1-old vaut 0{40} (ce qui signifie qu'il n'y a pas encore de référence de ce type), soit il devrait correspondre à ce qui est
enregistré dans refname.

Le hook doit se terminer avec un statut différent de zéro s'il veut interdire la mise à jour de la référence nommée.
Sinon, il devrait sortir avec zéro.

L'exécution réussie (un état de sortie nul) de ce hook ne garantit pas que la référence sera
effectivement être mis à jour, ce n'est qu'un préalable. En tant que tel, ce n'est pas une bonne idée d'envoyer
avis (par exemple, e-mail) de ce crochet. Envisagez plutôt d'utiliser le crochet post-réception.

POST-RECEPTION CROCHET

Une fois que toutes les références ont été mises à jour (ou tenté d'être mises à jour), si une mise à jour des références a été
réussi, et si le fichier $GIT_DIR/hooks/post-receive existe et est exécutable, il sera
invoqué une fois sans paramètre. L'entrée standard du crochet sera une ligne pour chaque
réf mis à jour avec succès :

sha1-ancien SP sha1-nouveau SP refname LF

La valeur du nom de référence est relative à $GIT_DIR ; par exemple pour la tête principale c'est
"refs/heads/master". Les deux valeurs sha1 avant chaque refname sont les noms d'objet pour le
refname avant et après la mise à jour. Les références qui ont été créées auront sha1-old égal à
0{40}, tandis que les références qui ont été supprimées auront sha1-new égal à 0{40}, sinon sha1-old
et sha1-new devraient être des objets valides dans le référentiel.

Les variables d'environnement GIT_PUSH_CERT* peuvent être inspectées, tout comme dans le hook de pré-réception,
après avoir accepté un push signé.

En utilisant ce hook, il est facile de générer des mails décrivant les mises à jour du référentiel.
Cet exemple de script envoie un message électronique par référence répertoriant les commits poussés vers le
référentiel et enregistre les certificats push des pushs signés avec de bonnes signatures dans un
service d'enregistrement :

#!/ Bin / sh
# envoyer par e-mail les informations de mise à jour du commit.
pendant la lecture ovale nval ref
do
if expr "$oval" : '0*$' >/dev/null
puis
echo "Créé une nouvelle référence, avec les commits suivants :"
git rev-list --pretty "$nval"
d'autre
echo "Nouveaux commits :"
git rev-list --pretty "$nval" "^$oval"
fi |
mail -s "Modifications apportées à ref $ref" commit-list@mydomain
fait
# certificat push signé par journal, le cas échéant
si test -n "${GIT_PUSH_CERT-}" && test ${GIT_PUSH_CERT_STATUS} = G
puis
(
echo nonce attendu est ${GIT_PUSH_NONCE}
git fichier blob ${GIT_PUSH_CERT}
) | mail -s "pousser le certificat de $GIT_PUSH_CERT_SIGNER" push-log@mydomain
fi
sortie 0

Le code de sortie de cette invocation de hook est ignoré, cependant un code de sortie différent de zéro
générer un message d'erreur.

Notez qu'il est possible que refname n'ait pas sha1-new lorsque ce hook s'exécute. Ceci peut
se produisent facilement si un autre utilisateur modifie la référence après sa mise à jour par git-recevoir-pack,
mais avant que le crochet ait pu l'évaluer. Il est recommandé que les crochets s'appuient sur sha1-new
plutôt que la valeur actuelle de refname.

POST-MISE À JOUR CROCHET

Après tout autre traitement, si au moins une référence a été mise à jour, et si
Le fichier $GIT_DIR/hooks/post-update existe et est exécutable, alors post-update sera appelé
avec la liste des références qui ont été mises à jour. Cela peut être utilisé pour implémenter n'importe quel référentiel
tâches de nettoyage étendues.

Le code de sortie de cette invocation de hook est ignoré ; la seule chose qui reste pour
git-recevoir-pack faire à ce stade est de se sortir de toute façon.

Ce hook peut être utilisé, par exemple, pour exécuter git update-server-info si le référentiel est
emballé et est servi via un transport muet.

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

Utilisez git-receive-pack en ligne en utilisant les services onworks.net