git-receive-pack: en línea en la nube

PROGRAMA:

NOMBRE

git-receive-pack: recibe lo que se envía al repositorio

SINOPSIS

paquete de recepción de git

DESCRIPCIÓN

Invocado por git paquete de envío y actualiza el repositorio con la información proveniente del
extremo remoto.

Este comando no suele ser invocado directamente por el usuario final. La interfaz de usuario del protocolo es
en git paquete de envío lado, y el par de programas está destinado a ser utilizado para enviar actualizaciones a
repositorio remoto. Para operaciones de extracción, consulte git-fetch-paquete(1).

El comando permite la creación y el avance rápido de sha1 refs (cabezas / etiquetas) en el
extremo remoto (estrictamente hablando, es el extremo local paquete de recepción de git corre, pero para el usuario
que está sentado en el extremo del paquete de envío, está actualizando el control remoto. ¿Confundido?)

Hay otros ejemplos del mundo real sobre el uso de ganchos de actualización y posterior a la actualización que se encuentran en el
Directorio de documentación / howto.

paquete de recepción de git respeta la opción de configuración Receive.denyNonFastForwards, que le indica si
las actualizaciones de una referencia deben denegarse si no son de avance rápido.

CAMPUS

El repositorio en el que sincronizar.

PRE-RECIBIR GANCHO

Antes de que se actualice cualquier referencia, si el archivo $ GIT_DIR / hooks / pre-receive existe y es ejecutable,
se invocará una vez sin parámetros. La entrada estándar del gancho será una línea.
por ref a actualizar:

sha1-antiguo SP sha1-nuevo SP refname LF

El valor de refname es relativo a $ GIT_DIR; por ejemplo, para el jefe maestro esto es
"refs / jefes / master". Los dos valores sha1 antes de cada refname son los nombres de objeto para el
refname antes y después de la actualización. Las referencias que se crearán tendrán sha1-old igual a 0 {40},
mientras que las referencias que se eliminarán tendrán sha1-new igual a 0 {40}, de lo contrario sha1-old y
sha1-new deben ser objetos válidos en el repositorio.

Al aceptar un push firmado (ver git-push(1)), el certificado push firmado se almacena en un
blob y una variable de entorno GIT_PUSH_CERT se pueden consultar para su nombre de objeto. Ver
la descripción del gancho posterior a la recepción por ejemplo. Además, el certificado es
verificado usando GPG y el resultado se exporta con las siguientes variables de entorno:

GIT_PUSH_CERT_SIGNER
El nombre y la dirección de correo electrónico del propietario de la clave que firmó el envío.
certificado.

GIT_PUSH_CERT_KEY
El ID de clave GPG de la clave que firmó el certificado push.

GIT_PUSH_CERT_STATUS
El estado de la verificación GPG del certificado push, utilizando el mismo mnemónico que
utilizado en% G? formato de la familia de comandos git log (ver registro de git(1)).

GIT_PUSH_CERT_NONCE
La cadena nonce que el proceso le pidió al firmante que la incluyera en el certificado push. Si
esto no coincide con el valor registrado en el encabezado "nonce" en el certificado push,
puede indicar que el certificado es válido y que se está reproduciendo desde un
sesión separada "git push".

GIT_PUSH_CERT_NONCE_STATUS

NO SOLICITADO
"git push --signed" envió un nonce cuando no le pedimos que enviara uno.

DESAPARECIDO
"git push --signed" no envió ningún encabezado nonce.

BAD
"git push --signed" envió un mensaje falso.

OK
"git push --signed" envió el nonce que le pedimos que enviara.

AGUA SUCIA
"git push --signed" envió un nonce diferente al que le pedimos que enviara ahora, pero
en una sesión anterior. Consulte la variable de entorno GIT_PUSH_CERT_NONCE_SLOP.

GIT_PUSH_CERT_NONCE_SLOP
"git push --signed" envió un nonce diferente al que le pedimos que enviara ahora, pero en un
sesión diferente cuya hora de inicio es diferente en tantos segundos de la
sesión actual. Solo tiene sentido cuando GIT_PUSH_CERT_NONCE_STATUS dice SLOP. También leer
acerca de la variable Receive.certNonceSlop en git-config(1).

Este gancho se llama antes de que se actualice cualquier refname y antes de que se realicen las comprobaciones de avance rápido.
realizado.

Si el gancho de pre-recepción sale con un estado de salida distinto de cero, no se realizarán actualizaciones,
y tampoco se invocarán los hooks de actualización, post-recepción y post-actualización. Esto puede ser
útil para rescatar rápidamente si la actualización no es compatible.

ACTUALIZAR GANCHO

Antes de que se actualice cada ref, si el archivo $ GIT_DIR / hooks / update existe y es ejecutable, es
invocado una vez por ref, con tres parámetros:

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

El parámetro refname es relativo a $ GIT_DIR; por ejemplo, para el jefe maestro esto es
"refs / jefes / master". Los dos argumentos sha1 son los nombres de objeto para el refname antes
y después de la actualización. Tenga en cuenta que se llama al gancho antes de que se actualice el nombre de referencia, por lo que
o sha1-old es 0 {40} (lo que significa que aún no existe dicha referencia), o debería coincidir con lo que es
registrado en refname.

El gancho debe salir con un estado distinto de cero si quiere no permitir la actualización de la referencia nombrada.
De lo contrario, debería salir con cero.

La ejecución exitosa (un estado de salida cero) de este gancho no garantiza que la referencia
ser actualizado, es solo un requisito previo. Como tal, no es una buena idea enviar
avisos (por ejemplo, correo electrónico) de este gancho. En su lugar, considere utilizar el enlace posterior a la recepción.

POST-RECIBIR GANCHO

Después de que se actualizaron todas las referencias (o se intentó actualizar), si se
exitoso, y si el archivo $ GIT_DIR / hooks / post-Receive existe y es ejecutable, será
se invoca una vez sin parámetros. La entrada estándar del gancho será una línea para cada
ref actualizado con éxito:

sha1-antiguo SP sha1-nuevo SP refname LF

El valor de refname es relativo a $ GIT_DIR; por ejemplo, para el jefe maestro esto es
"refs / jefes / master". Los dos valores sha1 antes de cada refname son los nombres de objeto para el
refname antes y después de la actualización. Las referencias que se crearon tendrán sha1-old igual a
0 {40}, mientras que las referencias que se eliminaron tendrán sha1-new igual a 0 {40}; de lo contrario, sha1-old
y sha1-new deben ser objetos válidos en el repositorio.

Las variables de entorno GIT_PUSH_CERT * se pueden inspeccionar, al igual que en el gancho de pre-recepción,
después de aceptar un push firmado.

Usando este gancho, es fácil generar correos que describan las actualizaciones del repositorio.
Este script de ejemplo envía un mensaje de correo por referencia que enumera las confirmaciones enviadas al
repositorio, y registra los certificados push de los envíos firmados con buenas firmas en un
servicio de registrador:

#!/ Bin / sh
# enviar información de actualización de confirmación por correo.
mientras lee oval nval ref
do
if expr "$ oval": '0 * $'> / dev / null
luego
echo "Creé una nueva referencia, con las siguientes confirmaciones:"
git rev-list - bastante "$ nval"
más
echo "Nuevas confirmaciones:"
git rev-list - bastante "$ nval" "^ $ oval"
fi |
mail -s "Cambios en ref $ ref" lista-de-compromiso @ midominio
hecho
# log certificado push firmado, si lo hubiera
si prueba -n "$ {GIT_PUSH_CERT-}" && prueba $ {GIT_PUSH_CERT_STATUS} = G
luego
(
El eco esperado es $ {GIT_PUSH_NONCE}
blob de archivo cat de git $ {GIT_PUSH_CERT}
) | mail -s "certificado push de $ GIT_PUSH_CERT_SIGNER" push-log @ mydomain
fi
salir de 0

El código de salida de esta invocación de gancho se ignora, sin embargo, un código de salida distinto de cero
generar un mensaje de error.

Tenga en cuenta que es posible que refname no tenga sha1-new cuando se ejecute este enlace. Esto puede
ocurren fácilmente si otro usuario modifica la referencia después de que fue actualizada por paquete de recepción de git,
pero antes el gancho pudo evaluarlo. Se recomienda que los ganchos se basen en sha1-new
en lugar del valor actual de refname.

POST-ACTUALIZACIÓN GANCHO

Después de todos los demás procesos, si se actualizó al menos una referencia y si
El archivo $ GIT_DIR / hooks / post-update existe y es ejecutable, luego se llamará post-update
con la lista de referencias que se han actualizado. Esto se puede utilizar para implementar cualquier repositorio.
amplias tareas de limpieza.

El código de salida de esta invocación de gancho se ignora; lo único que queda para
paquete de recepción de git hacer en ese punto es salir de todos modos.

Este gancho se puede usar, por ejemplo, para ejecutar git update-server-info si el repositorio es
embalado y se sirve a través de un transporte tonto.

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

Use git-receive-pack en línea usando los servicios de onworks.net