Français ▾ Topics ▾ Latest version ▾ git-receive-pack last updated in 2.50.0

NOM

git-receive-pack - Reçoit ce qui a été poussé dans un dépôt

SYNOPSIS

git receive-pack <rép-git>

DESCRIPTION

Invoqué par git send-pack et met à jour le dépôt avec les informations transmises depuis l’extrémité distante.

Cette commande n’est généralement pas invoquée directement par l’utilisateur final. L’interface pour le protocole se trouve du côté de git send-pack, et la paire de programmes est destinée à pousser les mises à jour vers un dépôt distant. Pour les opérations de récupération, voir git-fetch-pack[1].

La commande permet la création et l’avance rapide de réf. sha1 (heads/tags) sur l’extrémité distante (strictement parlant, c’est l’extrémité locale git-receive-pack qui s’exécute, mais pour l’utilisateur qui se trouve du côté de send-pack, c’est le distant qui est mis à jour. Confus ?)

Il existe d’autres exemples concrets d’utilisation des hooks update et post-update dans le répertoire Documentation/howto.

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

Plusieurs autres options de configuration receive.* sont disponibles pour ajuster son comportement, voir git-config[1].

OPTIONS

<rép-git>

Le dépôt dans lequel synchroniser.

--http-backend-info-refs

Utilisé par git-http-backend[1] pour servir les requêtes $GIT_URL/info/refs?service=git-receive-pack. Voir --http-backend-info-refs dans git-upload-pack[1].

--skip-connectivity-check

Contourne les vérifications de connectivité qui valident l’existence de tous les objets dans la fermeture transitive des objets accessibles. Cette option est destinée aux opérateurs de serveur qui souhaitent implémenter leur propre vérification de connectivité d’objets en dehors de Git. Cela est utile dans les cas où le côté serveur dispose d’informations supplémentaires sur l’utilisation de Git et peut donc s’appuyer sur certaines garanties pour calculer plus efficacement la connectivité des objets que Git lui-même ne peut fournir. L’utilisation de cette option sans mécanisme externe fiable pour assurer la complète connectivité des objets accessibles risque de corrompre le dépôt et ne devrait pas être utilisée en cas général.

HOOK PRE-RECEIVE

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 hook sera une ligne par référence à mettre à jour :

sha1-old SP sha1-new SP refname LF

La valeur de refname est relative à $GIT_DIR ; par exemple pour la tête master c’est "refs/heads/master". Les deux valeurs sha1 avant chaque refname sont les noms d’objet pour la référence 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 devraient être des objets valides dans le dépôt.

Lors de l’acceptation d’une poussée signée (voir git-push[1]), le certificat de poussée signé est stocké dans un blob et une variable d’environnement GIT_PUSH_CERT peut être consultée pour son nom d’objet. Voir la description du hook post-receive 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 certificat de poussée.

GIT_PUSH_CERT_KEY

L’identifiant de clé GPG de la clé qui a signé le certificat de poussée.

GIT_PUSH_CERT_STATUS

L’état de la vérification GPG du certificat de poussée, utilisant le même mnémonique que celui utilisé dans le format %G? de la famille de commandes git log (voir git-log[1]).

GIT_PUSH_CERT_NONCE

La chaîne nonce que le processus a demandé au signataire d’inclure dans le certificat de poussée. Si cela ne correspond pas à la valeur enregistrée dans l’en-tête "nonce" du certificat de poussée, cela peut indiquer que le certificat est un certificat valide qui est rejoué depuis une session "git push" séparée.

GIT_PUSH_CERT_NONCE_STATUS
UNSOLICITED

"git push --signed" a envoyé un nonce alors que nous ne lui avions pas demandé d’en envoyer un.

MISSING

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

BAD

"git push --signed" a envoyé un nonce erroné.

OK

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

SLOP

"git push --signed" a envoyé un nonce différent de celui que nous lui avons demandé d’envoyer maintenant, mais dans 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 celui que nous lui avons demandé d’envoyer maintenant, mais dans une session différente dont l’heure de début diffère de ce nombre de secondes par rapport à la session en cours. Significatif uniquement lorsque GIT_PUSH_CERT_NONCE_STATUS indique SLOP. Voir aussi la variable receive.certNonceSlop dans git-config[1].

Ce hook est appelé avant qu’aucun refname ne soit mis à jour et avant qu’aucune vérification de fast-forward ne soit effectuée.

Si le hook pre-receive se termine avec un état de sortie non nul, aucune mise à jour ne sera effectuée, et les hooks update, post-receive et post-update ne seront pas non plus invoqués. Cela peut être utile pour abandonner rapidement si la mise à jour n’est pas prise en charge.

Voir les remarques sur l’environnement de quarantaine ci-dessous.

HOOK UPDATE

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 référence, avec trois paramètres :

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

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

Le hook devrait se terminer avec un statut différent de zéro s’il souhaite interdire la mise à jour de la réf. nommée. Sinon il devrait se terminer 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 mise à jour, c’est uniquement un prérequis. En tant que tel, ce n’est pas une bonne idée d’envoyer des notifications (par exemple par e-mail) depuis ce hook. Envisagez plutôt d’utiliser le hook post-receive.

HOOK POST-RECEIVE

Après que toutes les références ont été mises à jour (ou tenté d’être mises à jour), si une mise à jour de référence a 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 hook sera une ligne pour chaque référence mise à jour avec succès :

sha1-old SP sha1-new SP refname LF

La valeur de refname est relative à $GIT_DIR ; par exemple pour la tête master c’est "refs/heads/master". Les deux valeurs sha1 avant chaque refname sont les noms d’objet pour la référence 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 dépôt.

Les variables d’environnement GIT_PUSH_CERT* peuvent être inspectées, comme dans le hook pre-receive, après avoir accepté une poussée signée.

En utilisant ce hook, il est facile de générer des e-mails décrivant les mises à jour du dépôt. Ce script exemple envoie un message e-mail par référence listant les commits poussés vers le dépôt, et journalise les certificats de poussée des poussées signées avec de bonnes signatures vers un service de journalisation :

#!/bin/sh
# mail out commit update information.
while read oval nval ref
do
	if expr "$oval" : '0*$' >/dev/null
	then
		echo "Created a new ref, with the following commits:"
		git rev-list --pretty "$nval"
	else
		echo "New commits:"
		git rev-list --pretty "$nval" "^$oval"
	fi |
	mail -s "Changes to ref $ref" commit-list@mydomain
done
# log signed push certificate, if any
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 certificate from $GIT_PUSH_CERT_SIGNER" push-log@mydomain
fi
exit 0

Le code de sortie de cette invocation de hook est ignoré, cependant un code de sortie non nul générera un message d’erreur.

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

HOOK POST-UPDATE

Après tous les autres traitements, 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 des tâches de nettoyage à l’échelle du dépôt.

Le code de sortie de cette invocation de hook est ignoré ; la seule chose restante pour git-receive-pack à ce moment-là est de se terminer de toute façon.

Ce hook peut être utilisé, par exemple, pour exécuter git update-server-info si le dépôt est empilé et servi via un transport simple.

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

ENVIRONNEMENT DE QUARANTAINE

Lorsque receive-pack reçoit des objets, ils sont placés dans un répertoire temporaire "dans la quarantaine" au sein du répertoire $GIT_DIR/objects et migrés dans le magasin d’objets principal uniquement après que le hook pre-receive s’est terminé. Si la poussée échoue avant cela, le répertoire temporaire est entièrement supprimé.

Cela a quelques effets et mises en garde visibles par l’utilisateur :

  1. Les poussées qui échouent en raison de problèmes avec le pack entrant, des objets manquants, ou en raison du hook pre-receive ne laisseront aucune donnée sur disque. Cela est généralement utile pour éviter que des poussées échouées répétées ne remplissent votre disque, mais peut rendre le débogage plus difficile.

  2. Tout objet créé par le hook pre-receive sera créé dans le répertoire de quarantaine (et migré uniquement s’il réussit).

  3. Le hook pre-receive NE DOIT PAS mettre à jour les références pour pointer vers des objets en quarantaine. Les autres programmes accédant au dépôt ne seront pas en mesure de voir les objets (et si le hook pre-receive échoue, ces références seraient corrompues). Par sécurité, toute mise à jour de référence provenant de pre-receive est automatiquement rejetée.

VOIR AUSSI

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

GIT

Fait partie de la suite git[1]

TRADUCTION

Cette page de manuel a été traduite par Jean-Noël Avila <jn.avila AT free DOT fr> et les membres du projet git-manpages-l10n. Veuillez signaler toute erreur de traduction par un rapport de bogue sur le site https://github.com/jnavila/git-manpages-l10n .