git-receive-pack - Online na nuvem

PROGRAMA:

NOME

git-receive-pack - Receba o que é enviado para o repositório

SINOPSE

git-receive-pack

DESCRIÇÃO

Invocado por git enviar pacote e atualiza o repositório com as informações fornecidas pelo
fim remoto.

Este comando geralmente não é invocado diretamente pelo usuário final. A IU para o protocolo é
na git enviar pacote lado, e o par de programas deve ser usado para enviar atualizações para
repositório remoto. Para operações pull, consulte git-fetch-pack(1).

O comando permite a criação e o avanço rápido de sha1 refs (heads / tags) no
extremidade remota (estritamente falando, é a extremidade local git-receive-pack corre, mas para o usuário
que está sentado no final do pacote de envio, ele está atualizando o remoto. Confuso?)

Existem outros exemplos do mundo real de uso de ganchos de atualização e pós-atualização encontrados no
Documentação / diretório howto.

git-receive-pack honra a opção de configuração receive.denyNonFastForwards, que diz se
atualizações para um ref devem ser negadas se não forem fast-forward.

OPÇÕES

O repositório para sincronizar.

PRÉ-RECEBER GANCHO

Antes de qualquer referência ser atualizada, se o arquivo $ GIT_DIR / hooks / pre-receive existe e é executável, ele
será chamado uma vez sem parâmetros. A entrada padrão do gancho será uma linha
por ref a ser atualizado:

sha1-antigo SP sha1-novo SP refname LF

O valor refname é relativo a $ GIT_DIR; por exemplo, para o chefe mestre, este é
"refs / heads / master". Os dois valores sha1 antes de cada refname são os nomes dos objetos para o
refname antes e depois da atualização. Refs a serem criados terão sha1-old igual a 0 {40},
enquanto os refs a serem excluídos terão sha1-new igual a 0 {40}, caso contrário, sha1-old e
sha1-new devem ser objetos válidos no repositório.

Ao aceitar um push assinado (ver git-push(1)), o certificado push assinado é armazenado em um
blob e uma variável de ambiente GIT_PUSH_CERT podem ser consultados para seu nome de objeto. Ver
a descrição do gancho pós-recebimento para um exemplo. Além disso, o certificado é
verificado usando GPG e o resultado é exportado com as seguintes variáveis ​​de ambiente:

GIT_PUSH_CERT_SIGNER
O nome e o endereço de e-mail do proprietário da chave que assinou o push
certificado.

GIT_PUSH_CERT_KEY
O ID da chave GPG da chave que assinou o certificado push.

GIT_PUSH_CERT_STATUS
O status da verificação GPG do certificado push, usando o mesmo mnemônico que
usado em% G? formato da família de comandos git log (veja git-log(1)).

GIT_PUSH_CERT_NONCE
A string nonce que o processo solicitou ao signatário para incluir no certificado push. Se
isso não corresponde ao valor registrado no cabeçalho "nonce" no certificado push,
pode indicar que o certificado é válido e está sendo reproduzido a partir de um
sessão "git push" separada.

GIT_PUSH_CERT_NONCE_STATUS

NÃO SOLICITADO
"git push --signed" enviou um nonce quando não solicitamos o envio.

FALTA
"git push --signed" não enviou nenhum cabeçalho nonce.

BAD
"git push --signed" enviou um nonce falso.

OK
"git push --signed" enviou o nonce que pedimos para enviar.

SLOP
"git push --signed" enviou um nonce diferente do que pedimos para enviar agora, mas
em uma sessão anterior. Consulte a variável de ambiente GIT_PUSH_CERT_NONCE_SLOP.

GIT_PUSH_CERT_NONCE_SLOP
"git push --signed" enviou um nonce diferente do que pedimos para enviar agora, mas em um
sessão diferente, cujo tempo de início é diferente por alguns segundos do
sessão atual. Faz sentido apenas quando GIT_PUSH_CERT_NONCE_STATUS diz SLOP. Também leia
sobre a variável receive.certNonceSlop em git-config(1).

Este gancho é chamado antes que qualquer refname seja atualizado e antes que qualquer verificação de avanço rápido seja
realizado.

Se o gancho de pré-recepção sair com um status de saída diferente de zero, nenhuma atualização será realizada,
e os ganchos de atualização, pós-recebimento e pós-atualização também não serão chamados. Isso pode ser
útil para resgatar rapidamente se a atualização não for suportada.

ATUALIZAÇÃO GANCHO

Antes de cada referência ser atualizada, se $ GIT_DIR / hooks / update file existe e é executável, é
invocado uma vez por ref, com três parâmetros:

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

O parâmetro refname é relativo a $ GIT_DIR; por exemplo, para o chefe mestre, este é
"refs / heads / master". Os dois argumentos sha1 são os nomes dos objetos para o refname antes
e após a atualização. Observe que o gancho é chamado antes que o refname seja atualizado, então
ou sha1-old é 0 {40} (o que significa que não existe tal referência ainda), ou deve corresponder ao que é
registrado em refname.

O gancho deve sair com status diferente de zero se quiser impedir a atualização da referência nomeada.
Caso contrário, ele deve sair com zero.

A execução bem-sucedida (um status de saída zero) deste gancho não garante que o ref irá
realmente atualizado, é apenas um pré-requisito. Como tal, não é uma boa ideia enviar
avisos (por exemplo, e-mail) a partir deste gancho. Considere usar o gancho pós-recebimento.

PÓS-RECEBIMENTO GANCHO

Depois que todas as refs foram atualizadas (ou tentaram ser atualizadas), se alguma atualização de ref foi
bem-sucedido, e se o arquivo $ GIT_DIR / hooks / post-receive existe e é executável, ele será
chamado uma vez sem parâmetros. A entrada padrão do gancho será uma linha para cada
ref. atualizada com sucesso:

sha1-antigo SP sha1-novo SP refname LF

O valor refname é relativo a $ GIT_DIR; por exemplo, para o chefe mestre, este é
"refs / heads / master". Os dois valores sha1 antes de cada refname são os nomes dos objetos para o
refname antes e depois da atualização. Refs que foram criados terão sha1-old igual a
0 {40}, enquanto os refs que foram excluídos terão sha1-new igual a 0 {40}, caso contrário, sha1-old
e sha1-new devem ser objetos válidos no repositório.

As variáveis ​​de ambiente GIT_PUSH_CERT * podem ser inspecionadas, assim como no gancho de pré-recebimento,
depois de aceitar um push assinado.

Usando este gancho, é fácil gerar emails descrevendo as atualizações para o repositório.
Este script de exemplo envia uma mensagem de e-mail por referência listando os commits enviados para o
repositório, e registra os certificados de push de pushes assinados com boas assinaturas para um
serviço de logger:

#!/ Bin / sh
# enviar informações de atualização de commit.
enquanto lê oval nval ref
do
se expr "$ oval": '0 * $'> / dev / null
então
echo "Criada uma nova ref, com os seguintes commits:"
git rev-list --pretty "$ nval"
outro
echo "Novos commits:"
git rev-list --pretty "$ nval" "^ $ oval"
fi |
mail -s "Mudanças para ref $ ref" commit-list @ mydomain
feito
# logar certificado de push assinado, se houver
se teste -n "$ {GIT_PUSH_CERT-}" && teste $ {GIT_PUSH_CERT_STATUS} = G
então
(
O nonce esperado de eco é $ {GIT_PUSH_NONCE}
git cat-file blob $ {GIT_PUSH_CERT}
) | mail -s "push certificado de $ GIT_PUSH_CERT_SIGNER" push-log @ mydomain
fi
sair 0

O código de saída desta invocação de gancho é ignorado, no entanto, um código de saída diferente de zero irá
gerar uma mensagem de erro.

Observe que é possível que refname não tenha sha1-new quando este gancho for executado. Isso pode
ocorrer facilmente se outro usuário modificar a referência após ela ter sido atualizada por git-receive-pack,
mas antes que o gancho pudesse avaliá-lo. É recomendado que os ganchos usem sha1-new
em vez do valor atual de refname.

PÓS-ATUALIZAÇÃO GANCHO

Após todos os outros processamentos, se pelo menos um ref foi atualizado, e se
$ GIT_DIR / hooks / post-update file existe e é executável, então post-update será chamado
com a lista de referências que foram atualizadas. Isso pode ser usado para implementar qualquer repositório
amplas tarefas de limpeza.

O código de saída desta invocação de gancho é ignorado; a única coisa que resta para
git-receive-pack fazer nesse ponto é sair de si mesmo.

Este gancho pode ser usado, por exemplo, para executar git update-server-info se o repositório for
embalado e servido em um transporte burro.

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

Use git-receive-pack online usando serviços onworks.net