Português (Brasil) ▾ Topics ▾ Latest version ▾ git-send-pack last updated in 2.43.0

NOME

git-send-pack - Impulsiona (push) os objetos através do protocolo Git para um outro repositório

RESUMO

git send-pack [--mirror] [--dry-run] [--force]
		[--receive-pack=<git-receive-pack>]
		[--verbose] [--thin] [--atomic]
		[--[no-]signed | --signed=(true|false|if-asked)]
		[<host>:]<diretório> (--all | <ref>…​)

DESCRIÇÃO

No lugar utilize git push que é um wrapper de maior hierarquia deste comando. Consulte git-push[1].

Invoca o comando git-receive-pack num repositório possivelmente remoto e atualiza-o a partir do repositório atual, enviando determinados refs.

OPÇÕES

--receive-pack=<git-receive-pack>

O caminho para o programa git-receive-pack no lado remoto. Às vezes, é útil durante um "push" ao enviar para um repositório remoto via ssh e você não tem o programa no diretório do $PATH predefinido.

--exec=<git-receive-pack>

O mesmo que --receive-pack=<git-receive-pack>.

--all

Em vez de definir de forma explicita quais são referências que devem ser atualizadas, atualize todos os cabeçalhos que existam localmente.

--stdin

Pegue a lista dos refs do stdin, um por linha. Caso haja refs utilizados na linha de comando, além desta opção, os refs do stdin serão processados após as da linha de comando.

Caso --stateless-rpc seja utilizado junto com esta opção, a lista de referências deverá estar no formato do pacote (linha-pkt). Cada ref deve estar num pacote separado e a lista deve terminar com um pacote liberado.

--dry-run

Faça tudo, exceto realmente enviar as atualizações.

--force

Normalmente, o comando se recusa a atualizar uma referência remota que não seja um ancestral com referência local usada para substituí-la. Esta opção desativa a verificação. Isso significa que o repositório remoto pode perder commits; use-o com cuidado.

--verbose

Rode de forma loquaz.

--thin

Envie um pacote "thin", que registra os objetos no formato "deltificado" com base nos objetos não inclusos no pacote para reduzir o tráfego de rede.

--atomic

Use uma transação atômica para atualizar as refs. Caso alguma das refs falhem na atualização, todo o "push" falhará sem alterar nenhuma das refs.

--[no-]signed
--signed=(true|false|if-asked)

Assine com GPG a solicitação de envio para atualizar as referências no lado receptor, para permitir que ela seja verificada pelos ganchos ou para que seja registrada. Se for false ou --no-signed, não haverá tentativa de assinatura. Se for true ou --signed, o push falhará se o servidor não suportar envios assinados. Se for definido como if-asked, assine, funciona apenas se o servidor suportar envios assinados. O envio também falhará se a chamada real para a opção gpg --sign falhar. Para mais detalhes sobre o recebimento consulte git-receive-pack[1].

--push-option=<texto>

Passa a cadeia de caracteres especificada como uma opção de envio para consumo por ganchos no lado do servidor. Se o servidor não for compatível com as opções de envio, ocorrerá um erro. Para mais detalhes consulte git-push[1] e githooks[5].

<host>

Um host remoto para hospedar o repositório. Quando esta parte é especificada, o git-receive-pack é invocado através do ssh.

<diretório>

O repositório que será atualizado.

<ref>…​

O ramo remoto refs que serão atualizados.

ESPECIFICANDO AS REFS

Existem três maneiras para definir quais as refs devem ser atualizadas na extremidade remota.

Com a opção --all, todas as referências que existem localmente são transferidas para o lado remoto. Você não pode especificar nenhum <ref> se usar esta opção.

Sem --all e sem qualquer <ref>, os cabeçalhos existentes no lado local e no lado remoto são atualizadas.

Quando um ou mais <ref> são especificadas de forma explicita (seja na linha de comando ou através da opção --stdin), pode ser um único padrão ou um par de padrões separados por dois-pontos ":" (isso significa que um nome de referência não pode ter dois-pontos). Um único padrão <nome> é apenas uma abreviação de <nome>:<nome>.

Cada par de padrões consiste no lado de origem (antes dos dois-pontos) e no lado do destino (após os dois-pontos). A referência que será enviada é determinada ao encontrar uma correspondência que corresponda o lado da origem, e o local para onde ela é enviada é determinada usando o lado do destino. As regras usadas para corresponder a uma referência são as mesmas regras usadas pelo git rev-parse para resolver um nome de referência simbólico. Consulte git-rev-parse[1].

  • É um erro caso <src> não corresponda exatamente a um dos refs locais.

  • É um erro caso <dst> coincida com mais de uma ref remota.

  • Caso <dst> não corresponda a nenhum ref remoto

    • é preciso iniciar com "refs/"; o <dst> é utilizado literalmente como destino neste caso.

    • <src> == <dst> e a referência que coincida com <src> não devem existir no conjunto de refs remotas; o "ref" que coincida com o <src> localmente é utilizado como o nome do destino.

Sem a opção --force, a referência <src> é armazenada no ramo remoto somente se o <dst> (destino) não existir ou se o <dst> for um subconjunto adequado (ou seja, um ancestral) de <src>. Essa verificação, conhecida como "verificação de avanço rápido" (fast-forward check), é realizada para evitar a substituição acidental da referência remota e a perda dos commits de outras pessoas a partir daí.

Com --force, a verificação do avanço rápido é desativado para todas as refs.

Opcionalmente, um parâmetro <ref> pode ser prefixado com um sinal de mais + para desativar a verificação de avanço rápido apenas nessa "ref".

GIT

Parte do conjunto git[1]