Scroll to navigation

dgit(1) dgit dgit(1)

NOME

dgit - integração git com o arquivo Debian

RESUMO

dgit [dgit-opts] clone [dgit-opts] package [suite] [./dir|/dir]
dgit [dgit-opts] fetch|pull [dgit-opts] [suite]
dgit [dgit-opts] build|sbuild|build-source [build-opts]
dgit [dgit-opts] pbuilder|cowbuilder [debbuildopts]
dgit [dgit-opts] push-source|push-built [dgit-opts] [suite]
dgit [dgit-opts] rpush-source|rpush-built build-host:build-dir [push args...]
dgit [dgit-opts] action ...

DESCRIÇÃO

dgit permite-lhe tratar o arquivo Debian como se fosse um repositório git. Por outro lado, permite a Debian publicar a fonte dos seus pacotes como ramos git, num formato que é utilizável diretamente por pessoas normais.

Isto é a referência de linha de comandos. Por favor leia os tutorial(is):

dgit-user(7) para utilizadores: editar, compilar e partilhar pacotes
dgit-nmu-simple(7) para DDs: fazer um NMU direto
dgit-maint-native(7) para maintainers de pacotes Debian-nativos
dgit-maint-debrebase(7) para maintainers: um fluxo de trabalho re-baseado em puro-git
dgit-maint-merge(7) para maintainers: um fluxo de trabalho de fusão de puro-git
dgit-maint-gbp(7) para maintainers que já usam o git-buildpackage
dgit-sponsorship(7) para patrocinadores e contribuidores patrocinados
dgit-downstream-dsc(7) configurar um dgit push para uma nova distribuição

Veja dgit(7) para informação detalhada sobre o modelo de dados, problemas comuns que se espera surgirem com certos tipos de pacotes, etc.

OPERAÇÕES

Consulta o arquivo e dgit-repos para construir uma vista git do histórico para package na suite (sid por predefinição) num directório novo (chamado ./package por predefinição); e também, descarrega quaisquer tarballs originais necessários.

A ponta git da suite é deixada no ramo local dgit/suite pronta a trabalhar, e no ramo de acompanhamento remoto dgit correspondente. O remoto origin será configurado para apontar para a árvore dgit-repos do pacote para a distribuição da qual a suite pertence.

suite pode ser uma combinação de várias suites subjacentes no formato mainsuite,subsuite...; veja SUITES COMBINADAS em dgit(7).

Para sua conveniência, o vcs-git remoto será configurado a partir do campo Vcs-Git do pacote, se um existir - mas note que no caso geral o histórico encontrado lá pode ser diferente ou mesmo desarticulado da vista do dgit. (Veja também dgit update-vcs-git.)

Consulta o arquivo e git-repos para atualizar a vista git do histórico para uma suite especificada (e descarrega tarballs de origem se necessário), e atualiza o ramo de acompanhamento remoto remotes/dgit/dgit/suite. Se o ramo atual for dgit/suite então o dgit fetch predefine para suite; caso contrário analisa debian/changelog e usa a suite especificada lá. Suite pode ser uma suite combinada, como para clone.
Faz dgit fetch, e depois funde o novo cabeçalho do ramo de acompanhamento remoto remotes/dgit/dgit/suite no ramo atual.
Confere o ramo local dgit/suite.

Se o ramo não existir, o dgit checkout cria-o, e configura-o do mesmo modo que o dgit clone faria. Nesse caso, se o ramo de acompanhamento remoto do arquivo não existir, o dgit checkout irá fazer um dgit fetch primeiro.

Note Bem: dgit checkout irá apenas fazer fetch se precisar. Se você já tiver um ramo de suite, e quer fundir o seu ramo com atualizações do arquivo, use dgit pull.

O dgit checkout irá precisar normalmente de aceder ao servidor de arquivo, para canonizar o nome de suite fornecido. A excepção é se você especificar o nome canónico, e o ramo (ou ramo de acompanhamento) já existir.

Corre dpkg-buildpackage com algumas opções apropriadas. As opções e argumentos após compilação serão passadas ao dpkg-buildpackage. Não é necessário usar dgit build quando se usa dgit; é OK usar uma abordagem que assegure que o pacote fonte gerado corresponde ao cometido git relevante.

O etiquetar, assinar e o envio real devem ser deixados para o dgit push.

As operações de compilação do dgit acedem à rede, para obter a opção -v certa. Veja -v, em baixo.

Compila o pacote fonte, e um ficheiro de alterações para um prospetivo envio de apenas-fonte, usando o dpkg-source.

O resultado é deixado em package_version.dsc e package_version_source.changes.

O etiquetar, assinar e o envio real deve ser deixado para dgit push-source, ou dgit push.

dgit build-source verifica que o pacote fonte gerado corresponde ao CABEÇALHO git (como canonizado com o modo quilt especificado, se aplicável). As outras opções de dgit *build* para não efetuar esta verificação durante a compilação, em vez disso, deixam isto para o dgit push.

Limpa a árvore de trabalho atual (de acordo com a opção --clean= em força).
Define, ou atualiza o seu url, o vcs-git remoto, e (a menos que - seja especificado) corre git fetch nele.

Por predefinição, é usado o campo Vcs-Git do .dsc de Debian sid, pois esse é provavelmente o mais atualizado. Pode ser especificada outra suite, ou . para indicar que o Vcs-Git do debian/control do cwd deve ser usado em vez deste.

Escreve um sumário de utilização.
Constrói o pacote fonte, usa sbuild para fazer compilação binária, e usa mergechanges para fundir os ficheiros de alterações de fonte e binário. Opções e argumentos após sbuild serão passadas ao sbuild. O resultado é deixado em pacote_versão_multi.changes.
O etiquetar, assinar e o envio real devem ser deixados para o dgit push.
Constrói o pacote fonte, usa pbuilder para fazer compilação binária, e usa mergechanges para fundir os ficheiros de alterações de fonte e binário. O resultado é deixado em pacote_versão_multi.changes.

Você deve assegurar que a sua definição de dgit --build-products-dir corresponde ao seu pbuilder --buildresult.

Os debbuildopts são passados ao pbuilder usando a sua opção --debbuildopts. Se você quiser passar outras opções ao pbuilder, use a opção do dgit --pbuilder: como descrita em baixo (lembre-se que as opções do dgit devem aparecer entre dgit e pbuilder).

Você deve assegurar no seu pbuilderrc que não tem a definição SOURCE_ONLY_CHANGES=yes pois isto pode causar problemas.

Como o dgit pbuilder, mas usa cowbuilder em vez de pbuilder.
Corre git-buildpackage com algumas opções apropriadas. As opções e argumentos após gbp-build são passadas ao git-buildpackage.

Por predefinição isto usa --quilt=gbp, assim o CABEÇALHO deve ser um ramo do estilo git-buildpackage, e não um ramo de patches aplicadas.

O etiquetar, assinar e o envio real devem ser deixados para o dgit push.

Faz um `upload': envia o CABEÇALHO atual para dgit-repos (como cometidos git), e para o arquivo (como um pacote fonte, compilado por este comando).

Este é o modo usual de enviar para Debian. É como dizer "atualiza o código fonte no arquivo para corresponder ao meu CABEÇALHO git, e deixa os auto-compiladores fazer o resto."

Mais detalhado: O dgit push-source compila um pacote fonte a partir do CABEÇALHO. Depois empurra o CABEÇALHO para o ramo dgit-repos da suite, ajusta o .changes para incluir quaisquer .origs que estão em falta no arquivo e exclui .origs que o arquivo tem (assim -sa e -sd não são necessários quando se compila para dgit push), faz uma etiqueta git assinada, edita o .dsc para conter um campo de metadados do dgit, corre o debsign para assinar o envio (.dsc e .changes), empurra a etiqueta assinada, e finalmente usa o dput para enviar o .changes para o arquivo.

O dgit push usa sempre o pacote, suite e versão especificados no debian/changelog e o .dsc, o qual tem de concordar. Se a linha de comandos especificar uma suite então essa também tem de corresponder.

Quando usado num ramo git-debrebase, o dgit chama git-debrebase para preparar o ramo para envio e empurrar de pacote fonte.

Com -C, dgit push-source efetua um dgit push-built, assegurando adicionalmente que nenhuns pacotes binário são enviados.

Faz um `upload' de um pacote previamente compilado, possivelmente incluindo binários. Envia o CABEÇALHO atual para dgit-repos (como cometidos git); e, envia o pacote fonte e binários previamente compilado para o arquivo.

O pacote tem de já estar compilado e pronto para enviar, com o .dsc e .changes deixados no directório pai. É normalmente melhor fazer a compilação também com o dgit (ex. com dgit sbuild): algumas ferramentas de compilação existentes passam opções que em nada ajudam ao dpkg-source por predefinição, o que pode resultar no pacote fonte compilado não ser idêntico à árvore do git.

O dgit irá verificar que o .dsc corresponde exatamente ao CABEÇALHO atual, assegurando que todos os utilizadores, sejam da vista git do dgit, ou do arquivo tradicional, vejam o mesmo pacote fonte.

Empurra o conteúdo do directório especificado numa máquina remota. Isto é como correr dgit push em build-host com src-dir como o directório atual; no entanto, as operações de assinar são feitas na máquina invocadora. Isto permite-lhe fazer um push quando o sistema que tem o código fonte (e quaisquer binários compilados) não tem acesso à chave:

1. Clonar na máquina de compilação (dgit clone)
2. Editar código na maquina de compilação (edit, git commit)
3. Compilar pacote na máquina de compilação (dgit build)
4. Testar pacote na máquina de compilação ou noutro lado qualquer (dpkg -i, test)
5. Enviar ao invocar dgit rpush na máquina com a sua chave GPG.

No entanto, a máquina de compilação tem de ser capaz de ssh ao repositório dgit. Se não for este já o caso, você tem de o organizar separadamente, por exemplo pelo uso de agente de encaminhamento de ssh.

Os argumentos restantes são tratados tal como o dgit push-source ou dgit push-built os iria tratar.

build-host e build-dir podem ser passados como argumentos separados; isto é assumido que seja o caso se o primeiro argumento conter nenhum : (excepto talvez um em [ ], para suportar endereços IPv6 literais).

Você vai precisar de versões semelhantes o suficiente do dgit na máquina de compilação e na máquina de invocação. A maquina de compilação precisa do gnupg instalado, com a sua chave pública, e a de qualquer patrocinado, no seu chaveiro (mas não a sua chave privada, obviamente).

Nomes alternativos configuráveis para dgit push-built e dgit rpush-built. Estes aliases irão no futuro alterar para significar dgit push-source e dgit rpush-source, e por isto eles atualmente geram um aviso.

O comportamento do dgit push é controlado pela opção de configuração de git dgit.default.push-subcmd:

source corre dgit push-source predefinição futura
built e correr dgit push-built
built,warn avisa, e corre dgit push-built predefinição atual
reject falha

Para o dgit rpush, o comportamento é controlado por dgit.default.rpush-subcmd, caindo para dgit.default.push-subcmd se não estiver definido. Porque o dgit rpush não é corrido tipicamente numa árvore de trabalho git, apenas opções globais de configuração git (e opções de linha de comandos -c) são relevantes.

Estas definições podem ser passadas em segurança a dgit mais antigo (via -c); o valor built irá ser suportado indefinidamente. Isto deve ser usado em scripts que precisam de trabalhar com ambas versões antigas do dgit (que não têm push-built) e novas versões (onde push-source é a predefinição).

Configura a árvore de trabalho atual da maneira que o dgit clone a iria configurar. Como correr dgit setup-useremail, setup-mergechangelogs e setup-gitattributes (mas apenas faz cada uma se o dgit estiver configurado para o fazer automaticamente). Você pode usar estes em qualquer repositório git, não apenas naqueles usados com outras operações do dgit. Não corre update-vcs-git (pois isso requer informação de empacotamento de Debian).
Define o nome.utilizador e o email.utilizador de árvore de trabalho a partir da configuração dgit específica-da-distribuição (dgit-distro.distro.user-name e .user-email), ou DEBFULLNAME ou DEBEMAIL.
Configura um ajudante de fusão git para o ficheiro debian/changelog o qual usa dpkg-mergechangelogs.
Set up the working tree's .git/info/attributes to disable all transforming attributes for all files. This is done by defining a macro attribute, dgit-defuse-attrs, and applying it to *. For why, see GITATTRIBUTES in dgit(7).

Se houver uma linha de atributo macro existente [attr]dgit-defuse-attrs em .git/info/attributes, mas for insuficiente, porque foi feita por uma versão anterior do dgit e o git desde isso introduziu novos atributos de transformação, isto modifica a macro para desativar as transformações mais recentes.

(Se já existir uma linha de atributo macro [attr]dgit-defuse-attrs em .git/info/attributes a qual faz o que o dgit requer (seja quais ficheiros afete), esta operação não faz mais nada. Este facto pode ser usado para derrotar ou derrotar parcialmente o dgit setup-gitattributes e portanto o dgit setup-new-tree.)

Pacotes fonte de formato `3.0 (quilt)' precisam de representação das alterações não apenas na-árvore mas também como patches em debian/patches. O dgit quilt-fixup verifica se isto foi feito; se não, o dgit irá fazer patches apropriadas em debian/patches e também cometer as alterações resultantes para git.

Isto é normalmente feito automaticamente pelo dgit build e dgit push.

O dgit irá tentar converter cada cometido relevante no seu histórico git numa nova patch quilt. O dgit não pode converter fusões não-triviais, ou certos tipos de histórico mais exótico. Se o dgit não puder encontrar uma linearização apropriada do seu histórico, por predefinição irá falhar, mas você pode pedir-lhe para gerar uma única patch esmagada em vez disto.

Quando usado com um ramo git-debrebase, o dgit irá pedir ao git-debrebase para preparar patches. No entanto, o dgit pode fazer patches em algumas situações onde o git-debrebase falha, assim dgit quilt-fixup pode ser útil por seu próprio direito. Para usar sempre o próprio gerador de patch do dgit em vez de git-debrebase make-patches, passe --git-debrebase=true ao dgit.

Veja FORMATO 3.0 (QUILT) em dgit(7).

Importa um pacote fonte de formato Debian, especificado pelo seu .dsc, para git, da maneira que o dgit fetch faria.

Isto faz cerca de metade do trabalho do dgit fetch: irá converter o .dsc num ramo git órfão novo. Como o dgit não tem acesso a um arquivo de pacote fonte correspondente ou conhecimento do histórico ele não considera se esta versão é mais recente que qualquer importação anterior ou ramos git correspondentes; e por isso não faz uma pseudo-fusão para vincular a importação a qualquer histórico git existente.

Porque um .dsc pode conter um campo Dgit a nomear um cometido git (o qual você pode não ter), e especificar onde encontrar tal cometido (e qualquer tabela de rescrita de histórico), o import-dsc pode precisar de acesso online. Se isto for um problema (ou se o esforço do dgit para encontrar o cometido falhar), considere --no-chase-dsc-distro ou --force-import-dsc-with-dgit-field.

Existe apenas uma sub-opção:

--require-valid-signature faz o dgit insistir que a assinatura no .dsc é válida (usando o mesmo critério que dpkg-source -x). Caso contrário, o dgit tenta verificar a assinatura mas o resultado é reportado apenas como mensagens para o stderr.

Se branch for prefixado com + então se já existir, será simplesmente sobrescrito, independentemente do conteúdo existente. Se branch for prefixado com .. então se já existir e o dgit realmente importar o dsc (em vez de ler simplesmente o cometido git a partir do campo Dgit), o dgit irá fazer uma pseudo-fusão para que o resultado seja necessariamente de avanço rápido a partir do ramo existente. Caso contrário, se branch já existir, o dgit irá parar com uma mensagem de erro.

Se branch não começar com refs/, é precedido com refs/heads/.

Consulta o arquivo por quaisquer tarballs de origem para este pacote e versão de autor, e descarrega-os.

A suite declarada no changelog será verificada primeiro.

Falhando isso, será procurado no arquivo inteiro por origs apropriados. Se existirem múltiplos conjuntos de origs que possam ser aplicados, falha com estado de saída 5. Isto pode acontecer se diferentes envios da mesma versão de autor tiverem diferentes origs.

Se os origs selecionados (alguns deles) já estiverem presentes localmente, eles não são re-descarregados, mas os seus sumários de verificação são verificados contra dados a partir do arquivo.

O download-unfetched-origs suporta algumas opções específicas de sub-comandos:

Escreve sumários de verificação dos origs selecionados em ficheiro, em formato sha256sum. Os ficheiros listados são um conjunto apropriado para um novo envio ou compilação, deste pacote e versão. O ficheiro de sumários de verificação é escrito e corrigido, mesmo que dgit download-unfetched-origs termine com estado 3.
Escreve informação de versão e termina.
Tenta obter uma cópia do código fonte para o dgit-repos-server, como sendo realmente usado no servidor git do dgit, como uma árvore git.
Escreve o url usado pelo dgit clone-dgit-repos-server. Espera-se que isto seja apropriado para usar como um url remoto de git. Pode não ser utilizável num navegador.
Escreve os argumentos -i e -I que têm de ser passados ao dpkg-souce para fazer com que execute exatamente o directório .git e mais nada. Os argumentos separados não são cotados, separados por espaços, e não contêm espaços.
Constrói uma tree-ish aproximando o estado de patches-não-aplicadas do seu pacote 3.0 (quilt), e escreve o nome de objeto git no stdout. Isto requer tarballs .orig apropriados. Este objeto árvore é idêntico ao seu .origs com respeito a ficheiros do autor. O conteúdo do sub-directório debian não é interessante e não deve ser inspecionado; excepto que debian/patches será idêntico ao seu CABEÇALHO.

Para fazer isto operar off-line, a chave de configuração de acesso que é usada para determinar o build-products-dir é a versão não canonizada do nome da suite a partir do registo de alterações, ou (claro) dgit.default.build-products-dir. Veja CONFIGURAÇÃO DE ACESSO, e baixo.

Esta função é fornecida principalmente para o benefício de git-debrebase.

OPÇÕES

Usa keyid para assinar a etiqueta e o envio A predefinição vem da definição de configuração keyid da distribuição (veja CONFIGURAÇÃO, em baixo), ou falhando isso, da linha atrelada de quem enviou em debian/changelog.
Não assina etiquetas nem envios (com significado apenas com push).
Especifica que devemos processar o pacote fonte pacote.

Para dgit fetch e dgit pull, usa este valor em vez de procurar em debian/control ou debian/changelog.

Para dgit rpush, especifica que a máquina que invoca deverá está disposta a assinar apenas um ficheiro .dsc ou .changes para o pacote fonte pacote.

Usa git clean -xdf para limpar a árvore de trabalho, em vez de correr o alvo de limpeza de regras do pacote.

Isto vai apagar todos os ficheiros que não são seguidos pelo git. (Incluindo quaisquer ficheiros que você esqueceu de adicionar ao git).

Outras opções --clean=... além de dpkg-source são úteis quando o alvo de limpeza do pacote é problemático, ou para evitar precisar das dependências de compilação.

O dgit irá apenas limpar a árvore se precisar (porque precisa de compilar o pacote fonte ou binários a partir da árvore de trabalho). Caso contrário irá apenas verificar que não existem ficheiros não seguidos e não ignorados. Veja --clean=git[-ff],always, em baixo.

Usa git clean -xdff para limpar a árvore de trabalho. Como git clean -xdf mas também remove quaisquer sub-directórios que contenham árvores git diferentes (o que apenas pacotes não usuais são prováveis de criar).
Como --clean=git, mas faz sempre a limpeza e não apenas uma verificação, apagando quaisquer ficheiros não seguidos e não ignorados.
Verifica meramente que a árvore está limpa (que não contém ficheiros não cometidos). Evita correr a limpeza de regras, e pode evitar o precisar das dependências de compilação.

Com ,ignores ou -wci, os ficheiros não seguidos cobertos por .gitignore são tolerados, assim apenas ficheiros que aparecem como ? no estado do git (isto é, aqueles que você talvez esqueceu de adicionar ao git) são tratados como um problema.

Não limpa a árvore, nem verifica se está limpa. Evita correr limpeza de regras, e pode evitar precisar de dependências de compilação. Se existirem ficheiros que não estão em git, ou se a compilação criar tais ficheiros, um dgit push subsequente irá falhar.
Usa dpkg-buildpackage para fazer a limpeza, para que o pacote fonte seja limpo pelo dpkg-source correndo o alvo de limpeza do pacote. --clean=dpkg-source é a predefinição.

Sem o d extra, requer as dependências de compilação do pacote.

Com ...-d ou -wdd, as dependências de compilação não são verificadas (devido a passar -d ao dpkg-buildpackage), o que viola a política, mas pode funcionar para praticar.

O alvo de limpeza de regras só será corrido se for necessário: quando o dgit vai compilar pacotes fonte ou binário a partir da sua árvore de trabalho, em vez do seu ramo git (por exemplo devido a --include-dirty ou porque a compilação do pacote binário usa a sua árvore de trabalho).

Em todos os casos, o dgit irá verificar que não existem (após a limpeza de regras, se aplicável) nenhuns ficheiros não seguidos e não ignorados, no caso destes serem ficheiros que você esqueceu de adicionar ao git. (Excepto que esta verificação não é feita para um pacote `3.0 (quilt)' quando o dgit tem de aplicar patches, de maneira suja, na árvore de trabalho.) Se o seu pacote não tiver um bom .gitignore você vai provavelmente precisar de --clean=dpkg-source,no-check também conhecido por -wdn.

Como --clean=dpkg-source, mas não se interessa por ficheiros não seguidos não ignorados.
Como --clean=dpkg-source, mas falha mesmo com ficheiros não seguidos ignorados. Isto pode talvez ser usado para detetar bugs no seu alvo de limpeza de regras.
O pacote é, ou pode ser, novo nesta suite. Sem isto, o dgit vai recusar o push. Precisar de --new não é fora do normal; por exemplo, é frequentemente necessário para enviar para Debian experimental.

Note que o dgit pode ser incapaz de aceder ao histórico git para um pacote completamente novo que não foi aceite pelo arquivo. Assim para um pacote completamente novo você precisa de coordenar apropriadamente com qualquer outra pessoa que possa enviar.

Não se queixa se a árvore de trabalho não corresponder ao seu CABEÇALHO git, e ao compilar, inclui as alterações a partir da árvore de trabalho. Isto pode ser útil com compilação, se planear cometer mais tarde. (o dgit push irá ainda assegurar que o .dsc você envia e a árvore git que empurra são idênticos, assim esta opção não vai fazer pushes quebrados.)

Note que isto não previne o dgit de limpar a sua árvore, assim se as alterações na sua árvore de trabalho estiverem na forma de ficheiros não seguidos, esses ainda podem ser apagados, especialmente com --clean=git. Se você quer incluir ficheiros não seguidos na compilação, pode usar --clean=none ou --clean=dpkg-source[-d] adicionalmente a --include-dirty. Note que esta combinação pode falhar se os ficheiros não seguidos estiverem sob debian/patches/.

Nome alternativo descontinuado para --include-dirty.
Faz o dgit push comportar-se mais apropriadamente para colaboração (usando histórico git partilhado) com co-desenvolvedores que usam git e não usam dgit.

Com esta opção, o dgit não se importa que o histórico git que você está a usar não seja necessariamente de avanço rápido a partir da vista dgit; em vez disso, vai confiar no registo de alterações para prevenir alterações acidentais que sobrescrevem.

E, os cometidos sintéticos precisos para tornar o histórico git do dgit de avanço rápido irão aparecer apenas no servidor git do dgit, e em ramos da suite dgit locais, não no seu próprio ramo principal. Assim eles não irão acabar no histórico visível ao maintainer, quando você empurra o seu próprio ramo para fazer um pedido de fusão.

Isto é equivalente a --split-view=always --trust-changelog.

Declara que o seu CABEÇALHO realmente contém todas as (necessárias) alterações de todas as versões listadas no seu registo de alterações; ou, todas as (necessárias) alterações a partir de previous-version. Esta promessa é necessária quando o seu ramo git não é um descendente da versão no arquivo de acordo com o histórico de revisão git.

É mais seguro especificar --trust-changelog, que --overwrite=previous-version, e geralmente a segunda não é necessária.

--trust-changelog é útil se você for o maintainer, e incorporou alterações NMU no seu próprio fluxo de trabalho git num modo que não torna o seu ramo de avanço rápido a partir do NMU. Também pode ser útil quando existiu um envio feito sem dgit desde o envio mais recente feito com o dgit.

É também geralmente necessário a primeira vez que um pacote é empurrado com dgit push para uma suite particular. Veja dgit-maint-*(7).

Com --trust-changelog o dgit vai verificar que a versão no arquivo é mencionada no seu debian/changelog. (Isto vai evitar perder alterações, a menos que alguém tenha cometido para git uma entrada finalizada no registo de alterações, e depois mais tarde feito alterações nessa versão.)

Com --overwrite=previous-version essa versão deveria ser a versão atualmente no arquivo, e será incondicionalmente sobrescrita, independentemente do que está no registo de alterações.

Estas opções irão, se necessário, fazer uma pseudo-fusão (isto é, algo que se parece com o resultado de git merge -s ours) para coser a versão do arquivo no seu próprio histórico git, para que o seu empurrar seja de avanço rápido a partir do arquivo.

(Em modo quilt gbp, dpm, unpatched ou baredebian*, implicar uma divisão entre a vista dgit e a vista de maintainer, a pseudo-fusão irá aparecer apenas na vista do dgit; pode ser usado --split-view=always para forçar esse comportamento, por exemplo, em outros modos quilt.)

--overwrite sem um número de versão é uma maneira obsoleta de especificar --trust-changelog.

Envia para uma fila de espera ATRASADA.

AVISO: Se o maintainer responder cancelando o seu envio da fila, e não fizer um envio ele próprio, isto não irá retroceder o ramo git no servidor git do dgit. Os outros utilizadores do dgit irão ver o seu push (com uma mensagem de aviso do dgit) mesmo que o maintainer tenha querido aboli-lo. Tais utilizadores podem reintroduzir as suas alterações sem o quererem.

Se esta situação surgir, alguém deve fazer um dgit push apropriado para atualizar o conteúdo de dgit-repos para uma versão sem as alterações controversas.

Diz ao dgit para não procurar online por repositórios git adicionais que contenham informação sobre um .dsc particular a ser importado. A predefinição é perseguir.

Para a maioria das operações (como fetch e pull), desativar a perseguição significa que o dgit irá aceder apenas ao servidor git para a distribuição que você está a trabalhar diretamente, mesmo que o .dsc tenha sido copiado literalmente a partir de outra distribuição. Para import-dsc, desativar a perseguição significa que o dgit vai trabalhar completamente offline.

Desativar a perseguição pode ser perigoso: se o .dsc nomear um cometido git que foi rescrito por quem está encarregue da distribuição, esta opção pode impedir esse rescrever de ser efetivo. Também, pode significar que o dgit falha ao encontrar os cometidos git necessários.

Especifica que a vista dividida está em operação, e o dgit calcula (ou procura na sua cache) uma vista dgit que corresponde ao seu CABEÇALHO. a vista dgit será deixada em ref. O ref especificado é sobrescrito incondicionalmente, portanto não especifique um ramo que deseja manter.

Esta opção é efetiva apenas com as seguintes operações: quilt-fixup; push; todas as compilações. E só é efetiva quando a vista dividida está realmente em operação.

Se ref não começar com refs/ é tomado como sendo um ramo - isto é, é anteposto refs/heads/.

--dgit-view-save é um nome alternativo descontinuado para --save-dgit-view.

Declara que você está deliberadamente a fazer algo. Isto pode ser usado para sobrepor travas de segurança, incluindo travas de segurança que se relacionam com políticas específicas da distribuição. O uso de --deliberately é declarado e publicado nas etiquetas assinadas geradas para si pelo dgit, para que o software do arquivo possa dar efeito à sua intenção, e para o benefício de humanos a olhar para o histórico. Os significados da compreensão de algo no contexto de Debian estão discutidos em baixo:
Declara que você está deliberadamente a rescrever o histórico. Isto pode acontecer porque o seu ramo não é de avanço rápido a partir do histórico do servidor dgit, ou não de avanço rápido a partir de uma importação dsc sintetizada localmente.

Quando empurrar para Debian, use isto apenas quando está a fazer um envio renovado de um pacote fonte completamente novo cuja versão anterior não foi aceite para lançamento de NOVO devido a problemas com direitos de cópia ou redistribuição; ou, excecionalmente, para o mesmo primeiro envio feito com dgit.

Quando a vista dividida está em operação, também previne a construção pelo dgit de uma pseudo-fusão para tornar a vista dgit de avanço rápido. Normalmente apenas um de --trust-changelog (o qual cria uma pseudo-fusão apropriada) e --deliberately-not-fast-forward (o qual suprime a pseudo-fusão e as verificações de avanço rápido) deve ser necessário; --trust-changelog é geralmente melhor.

Declara que você está deliberadamente a incluir, no histórico git do seu empurrar atual, história que contém uma versão anteriormente cometida deste pacote a qual não foi aprovada (ou ainda não foi aprovada) pelos mestres de ftp. Ao empurrar para Debian, apenas use esta opção após verificar isto: nenhuma das versões rejeitadas-a-partir-de-NOVO (ou nunca-aceites) no histórico git do seu empurrar atual, foram rejeitadas pelo mestre de ftp por razões de direitos de cópia e redistribuição.
Declara que você está deliberadamente a rescrever o histórico e quer descartar o repositório existente. Não relevante ao empurrar para Debian, pois o servidor Debian irá fazer isto automaticamente quando necessário.
Com formato `3.0 (quilt)', insiste numa pilha de patch linear: uma nova patch para cada cometido relevante. Se tal pilha não puder ser gerada, falha. Esta é a predefinição para Debian.

CABEÇALHO deve ser uma série de cometidos simples (que não tocam em debian/patches/), e pseudo-fusões, tendo como antepassado um ramo de patches aplicadas.

Com formato `3.0 (quilt)', prefere uma pilha de patch linear (tal como com --quilt=linear) mas se isso não for possível, tenta gerar uma única patch esmagada com todas as alterações feitas em git (como com --quilt=smash). Isto não é uma boa ideia para um NMU em Debian.
Com formato `3.0 (quilt)', assume patches aplicadas (como obtido a partir de dgit clone) e gera uma patch adicional única para todas as alterações feitas em git. Isto não é uma boa ideia para um NMU em Debian.

(Se CABEÇALHO já tiver quaisquer patches em-árvore, elas têm de aplicar de forma limpa. Isto será o caso para quaisquer árvores produzidas por dgit fetch ou clone; se você não alterar a versão de autor nem fizer alterações em debian/patches, irá permanecer verdadeiro.

Com formato `3.0 (quilt)', assume patches aplicadas (como obtido a partir de dgit clone), apaga todas as patches existentes, e depois gera uma patch única para todas as alterações feitas em git. Isto não é uma boa ideia para um NMU em Debian.

Use isto em vez da opção de formato dpkg-source single-debian-patch. Essa opção do dpkg-source não consegue lidar com certas alterações na árvore que o dpkg-source caso contrário permite, e nalguns casos pode gerar pacotes fonte estranhos que o dpkg-source parece aceitar mas que tornam-se corrompidos quando mais tarde pessoas tentam modifica-los.

Com formato `3.0 (quilt)', assume patches aplicadas (como obtido a partir de dgit clone), e verifica se os metadados da patch estão atualizados. Se não estiverem, falha; você próprio tem então de corrigir os metadados de algum modo antes de empurrar. (Note bem que dpkg-source --commit não vai funcionar porque a árvore git do dgit não tem um directório .pc.)
Com formato `3.0 (quilt)', assume que a árvore é patches aplicadas (como obtido a partir de dgit clone), e assume que os metadados da patch estão atualizados. Se você usar esta opção e os metadados da patch estiverem desatualizados, o dgit push vai falhar.
--[quilt=]gbp | --[quilt=]dpm | --quilt=unapplied | --[quilt=]baredebian[+git|+tarball]
Diz ao dgit que você está a usar um ramo git quase-compatível-com-dgit, também conhecido por vista de maintainer, e não quer o seu ramo alterado pelo dgit.

Estes modos quilt são conhecidos por modos quilt de divisão. Veja --split-view, em baixo.

--gbp (curto para --quilt=gbp) é para usar com git-buildpackage. Espera-se que o seu CABEÇALHO seja um ramo git de patches não aplicadas, excepto que pode conter alterações aos ficheiros .gitignore do autor. Esta é a predefinição para dgit gbp-build.

--dpm (curto para --quilt=dpm) é para usar com git-dpm. Espera-se que o seu CABEÇALHO seja um ramo git de patches aplicadas, excepto que pode conter alterações aos ficheiros .gitignore do autor.

--quilt=unapplied especifica que o seu CABEÇALHO é um ramo git de patches não aplicadas (e que quaisquer alterações aos ficheiros .gitignore do autor são representados como patches em debian/patches).

--quilt=baredebian (ou o seu nome alternativo --quilt=baredebian+git) especifica que o seu CABEÇALHO contém apenas um directório debian/, com quaisquer aos ficheiros do autor representados como patches em debian/patches. A fonte do autor tem de estar disponível em git, por predefinição, numa etiqueta git com nome apropriado; veja --upstream-commitish. Neste modo, o dgit não pode verificar que todos os ficheiros de autor editados estão representados apropriadamente como patches: o dgit confia que debian/patches esteja correto.

--quilt=baredebian+tarball é como --quilt=baredebian, mas é usado quando não há um histórico git apropriado. Para construir a vista dgit, o dgit vai importar o conteúdo dos seus tarballs de origem para git. Neste modo, o dgit não pode verificar que as partes de autor do seu envio correspondem ao que você pretende: o dgit depende da existência dos tarballs de origem corretos , e que debian/patches esteja correto.

Com --quilt=gbp|dpm|unapplied|baredebian*, o dgit push (ou precursores como quilt-fixup e build) vão automaticamente gerar uma conversão do seu ramo git para o formato correto. O dgit push vai empurrar o formato compatível com dgit (a vista dgit) para o servidor git do dgit. A vista dgit irá ficar visível para si nos ramos de acompanhamento remoto do dgit, mas o seu próprio ramo não será modificado. O dgit push vai criar a etiqueta debian/versão para a vista de maintainer, e a etiqueta dgit archive/debian/versão para a vista dgit. O dgit quilt-fixup vai meramente fazer algumas verificações, e meter em cache a vista do maintainer.

Se você tem um ramo como este é essencial especificar a opção --quilt= apropriada! Isto porque nem sempre é possível distinguir: por exemplo, um ramo git de patches não aplicadas de um pacote com uma patch, parece-se muito com um ramo de patches aplicadas onde o utilizador tem usado reversão git para desfazer a patch, esperando que realmente e reverta. No entanto, se você falhar ao especificar a opção --quilt certa, e não estiver com muita sorte, o dgit vai reparar no problema e parar, com uma dica útil.

Especifica que a suite aonde operar faz parte da distribuição distro. Isto sobrepõe o valor predefinido encontrado a partir da opção de configuração git dgit-suite.suite.distro. O único efeito é que outras variáveis de configuração (usadas para acesso ao arquivo e repositório dgit) usadas são dgit-distro.distro.*.

Se a sua suite faz parte duma distribuição que o dgit já conhece, você pode usar esta opção para fazer o dgit funcionar mesmo que o seu dgit não conheça a suite. Por exemplo, especificar -ddebian irá funcionar quando a suite é uma suite desconhecida no arquivo Debian.

Para definir uma nova distribuição é necessário definir métodos e URLs para a obter (e, para o dgit push, alterar) uma variedade de informação ambos para o arquivo e o repositório dgit. Como definir isto ainda não está documentado.

Controla se o dgit opera uma vista dividida, separando o seu próprio ramo (como maintainer Debian) daquele mostrado aos utilizadores de dgit clone e dgit fetch.

Quando a vista dividida está em operação o dgit não vai fazer nem fundir nenhuns cometidos para o seu próprio ramo. Especificamente, apenas a vista dgit irá conter pseudo-fusões do dgit, que trazem para o histórico git envios anteriores feitos com dgit push, e quaisquer cometidos em debian/patches requeridos para fazer um pacote fonte `3.0 (quilt)' correto.

auto é a predefinição, e divide a vista apenas quando é necessário: isto é, quando você está a trabalhar com um pacote fonte `3.0 (quilt)' e um modo quilt de divisão: --[quilt=]gbp, dpm, unpatched ou baredebian*.

always divide a vista independentemente do formato da fonte e do modo quilt.

never irá fazer o dgit falhar se a vista dividida for necessária.

Quando a vista dividida está em operação, a vista dgit é visível no seu clone git local, mas apenas em refs específicos para dgit: notavelmente remotes/dgit/dgit/suite e archive/distro/versão.

Note que a vista dividida não afeta o dgit fetch, e não é compatível com dgit pull.

Especifica o ficheiro .changes que é para ser enviado. Por predefinição o dgit push procura um único ficheiro .changes no directório pai cujo nome de ficheiro sugere que é para o pacote e versão corretos.

Se o nome de caminho do changesfile especificado conter barras, a parte de directório é também usada como o valor para --build-products-dir; caso contrário, o ficheiro de alterações é esperado nesse directório (por predefinição, em ..).

Para usar apenas com --quilt=baredebian. Especifica o cometido que contém a fonte do autor. Este cometido tem de ser idêntico ao seu tarball .orig. A predefinição é procurar por uma das etiquetas git U vU upstream/U (por essa ordem), onde U é a versão de autor.
Ao efetuar uma compilação, apaga quaisquer ficheiros de alterações que correspondam a pacote_versão_*.changes antes de começar. Isto assegura que o dgit push (e o dgit sbuild) será capaz de identificar de forma inequívoca os ficheiros de alterações relevantes a partir da compilação mais recente, mesmo que tenha havido compilações anteriores com ferramentas ou opções diferentes. A predefinição é não remover, mas --no-rm-old-changes pode ser usado para sobrepor um --rm-old-changes anterior ou a definição de configuração .rm-old-changes.

Note que dgit push-source vai sempre encontrar o .changes certo, independentemente desta opção.

Especifica onde procurar e criar tarballs, pacotes binário, pacotes fonte, ficheiros .changes, e mais do mesmo.

Por predefinição, o dgit usa o directório pai (..).

Modificar esta definição pode necessitar de mover tarballs .orig para o novo directório, assim é provavelmente melhor usar a definição de configuração dgit.default.build-products-dir (veja CONFIGURAÇÃO em baixo) que esta opção de linha de comandos sobrepõe.

Não apaga o directório de destino se o clone falhar.
Se deve-se empurrar uma etiqueta DEP-14 (ex debian/versão) assim como uma etiqueta dgit (ex archive/debian/versão).

A predefinição é empurrar uma etiqueta DEP-14. Em modo de divisão, uma etiqueta DEP-14 é sempre empurrada, independentemente desta opção.

--always-dep14tag é um nome alternativo obsoleto para --dep14tag, retido para compatibilidade.

Se deve-se usar uma etiqueta DEP-14 existente, ou fazer uma nova. Ignorado se nenhuma etiqueta DEP-14 vai ser empurrada.
Empurra uma etiqueta DEP-14 existente. Se não houver uma etiqueta existente, ou a etiqueta existente for inapropriada, falha.
Empurra uma etiqueta DEP-14, se existir. Se não houver uma etiqueta existente, cria uma. Se existir uma etiqueta mas for inapropriada, falha.

Isto é a predefinição.

Empurra uma etiqueta DEP-14 existente, se existir e for apropriada. Se não existir uma etiqueta, ou for inapropriada, cria uma nova, sobrescrevendo o ref git correspondente, e assim apagando qualquer etiqueta antiga.
Cria sempre uma etiqueta DEP-14 nova, sobrescrevendo o ref git correspondente, e assim apagando qualquer etiqueta antiga.

Isto foi a predefinição no dgit 11 e anteriores.

Se deve-se verificar uma etiqueta DEP-14 existente, como parte da verificação de adequação.

A predefinição é considerar uma etiqueta não assinada apropriada (e não verificar uma assinada).

Note que qualquer etiqueta DEP-14 a ser empurrada será, efetivamente, contra assinada: a cinza do objeto etiqueta DEP-14 (se existir uma) é parte dos metadados na mensagem de etiqueta archive/ da vista dgit.

Escreve informação de depuração para o stderr. Repetir a opção produz mais resultados (atualmente, até -DDDD é significativamente diferente).
Controla se deve-se reter o directório de trabalho "de brincar" .git/dgit/unpack mesmo em sucesso, para exame e depuração. A predefinição é --no-keep-playground o que apaga o directório após execução com sucesso.
Especifica uma opção de configuração git, para ser usada nesta execução. O próprio dgit é também controlado por opções de configuração do git.
Especifica a opção -vversão a passar ao dpkg-genchanges, durante compilações. As alterações (a partir de debian/changelog) desde esta versão serão incluídas no ficheiro de alterações da compilação, e assim no envio. Se esta opção não for especificada, o dgit vai consultar o arquivo e usar a versão mais recente enviada para a suite destinada.

Especificar _ inibe isto, de maneira que nenhuma opção -v será passada ao dpkg-genchanges (e como resultado, apenas a última estrofe de debian/changelog será usada para a compilação e envio).

Passado ao dpkg-genchanges (eventualmente).
Especifica uma única opção adicional a passar eventualmente, ao dpkg-genchanges.

Opções que são seguras de passar incluem -C (e também -si -sa -sd apesar destas nunca deverem ser necessárias com Debian pois o dgit calcula automaticamente se .origs precisam de ser enviados.)

Para outras opções aplica-se o aviso em baixo.

Especifica uma única opção adicional a passar ao curl, dput, debsign, dpkg-source, dpkg-buildpackage, dpkg-genchanges, sbuild, pbuilder, cowbuilder, ssh, dgit, git-debrebase, apt-get, apt-cache, gbp-pq, gbp-build, ou mergechanges. Pode ser repetida como necessário.

O uso desta habilidade não deve normalmente ser necessário. É fornecido para contornar bugs, ou outras situações não usuais. Se você usar estas opções, você pode violar as suposições do dgit sobre o comportamento dos seus sub-programas e causar perdas.

Para dpkg-buildpackage, dpkg-genchanges, mergechanges e sbuild, a opção aplica-se apenas quando o programa é invocado diretamente pelo dgit. Normalmente, para passar opções ao dpkg-genchanges, você deve usar --ch:opção.

Especificar --git não é efetivo para algumas operações git de baixo-nível e apenas-leitura efetuadas pelo dgit, e também não é quando o git é invocado por outro programa corrido pelo dgit.

As opções --curl são atualmente ignoradas, porque o dgit usa libcurl em vez de curl(1).

Veja as notas em baixo sobre ssh e dgit.

Note Bem que --gpg:option não é suportado (porque debsign não tem essa facilidade). Mas veja -k e a definição de configuração da distribuição keyid.

Especifica uma opção a remover da linha de comandos para um programa chamado pelo dgit, como para --programa:opção (e os mesmos alertas aplicam-se).

Quaisquer opções ou argumentos exatamente idênticos a opção são removidas. (Não é um erro se não existirem nenhumas.)

Isto só pode ser usado para apagar opções que são sempre passadas por predefinição ao dgit, ou para desfazer um --programa:opção anterior. Não pode ser usado para sobrepor opções decididas dinamicamente pelo dgit.

Especifica programas alternativos a usar em vez de curl, dput, debsign, dpkg-source, dpkg-buildpackage, dpkg-genbuildinfo, dpkg-genchanges, dpkg-query, sbuild, pbuilder, cowbuilder, gpg, ssh, dgit, git-debrebase, apt-get, apt-cache, git, gbp-pq, gbp-build, ou mergechanges.

Para dpkg-buildpackage, dpkg-genbuildinfo, dpkg-genchanges, dpkg-query, mergechanges e sbuild, isto aplica-se apenas quando o programa é invocado diretamente pelo dgit.

Para dgit, especifica o comando a correr na máquina remota quando o dgit rpush precisa de invocar uma cópia remota dele próprio. (O dgit também se re-invoca a ele próprio como o EDITOR para dpkg-source --commit; isto é feito usando argv[0], e não é afetado por --dgit=).

O valor de gbp-build e usado em vez de gbp build ou git-buildpackage. (A predefinição é último a menos que o anterior exista na PATH.) O valor de gbp-pq é usado em vez de gbp pq. Em ambos casos, não usualmente, o valor especificado é dividido no espaço em branco para produzir um comando e possivelmente algumas opções e/ou argumentos.

Para o pbuilder e cowbuilder, as predefinições são sudo -E pbuilder e sudo -E cowbuilder respetivamente. Como com gbp-build e gbp pq, o valor especificado é dividido no espaço branco.

Para ssh, o valor predefinido é tirado das variáveis de ambiente DGIT_SSH ou GIT_SSH, se definidas (veja em baixo). E, para ssh, quando se acede ao arquivo e repositório dgit, esta definição de linha de comandos é sobreposta pelas variáveis de configuração do git dgit-distro.distro.ssh e .dgit.default.ssh (que por sua vez podem ser sobrepostas com -c). Também, quando o dgit usa o git para aceder ao repositório dgit, apenas a ideia do git sobre que ssh usar (ex, GIT_SSH) é relevante.

O dgit push precisa de canonizar o nome da suite. Por vezes, o dgit não tem maneira de pedir ao arquivo para fazer isto sem saber o nome de um pacote existente. Sem --new nós podemos apenas usar o pacote que estamos a tentar empurrar. Mas com --new isso não vai funcionar, então adivinhamos dpkg ou usamos o valor desta opção. Esta opção não é necessária com os mecanismos predefinidos para se aceder ao arquivo.
Escreve um sumário de utilização.
O dgit rpush usa um directório temporário na máquina (assinando) que invoca. Esta opção faz o dgit usar directório em vez disto. Mais anda, o directório especificado irá ser esvaziado, removido e re-criado antes do dgit começar, em vez de ser removido após o dgit terminar. O directório especificado tem de ser um nome de caminho absoluto.
Faz todos os movimentos, buscando toda a informação necessária, mas não atualiza realmente os resultados. Para empurrar, o dgit faz as verificações requeridas e deixa os novos .dsc e .changes em ficheiros temporários, mas não assina, etiqueta, empurra nem envia.

Isto não é uma simulação muito boa. Pode facilmente falhar em maneiras que um empurrar real não falharia.

Faz muitos mais movimentos: faz tudo que não envolva nem assinar coisas, nem fazer alterações nos servidores públicos.

Usar isto irá criar etiquetas não assinadas, e possivelmente outras alterações locais, que irão atrapalhar num empurrar real. Assim esteja preparado para queimar o número de versão que está a usar.

Instrui o dgit para tentar prosseguir apesar da deteção de que ele pensa que vai ser um problema fatal. Isto provavelmente não vai funcionar. Estas opções são fornecidas como saída de emergência, no caso do dgit estar confuso. (Também podem ser úteis para casos de teste de erros.)
Diz ao dgit import-dsc para tratar um .dsc com um campo Dgit como sendo um sem ele. O resultado é um importar fresco, descartando o histórico git em que a pessoa que empurrou esse .dsc estava a trabalhar.
Continua mesmo que isso envolva reutilizar um número de versão de um empurrar ou envio anterior. É normalmente melhor dar a diferentes versões diferentes números. Alguns servidores (incluindo, geralmente, o servidor Debian) vão rejeitar tentativas de reutilizar ou substituir versões já empurradas.
Continua e envia binários mesmo que o dgit pense que a sua distribuição não permite isso.
Continua e faz um envio de apenas-fonte, sem quaisquer binários, mesmo que o dgit pense que a sua distribuição não permite isso, ou não permite isso nesta situação.
Continua mesmo que o dgit pense que a sua árvore git contenha alterações (relativas aos seus tarballs .orig) as quais o dpkg-source não é capaz de representar. A sua compilação ou empurrar vai provavelmente falhar mais tarde.
Usa o conjunto de .origs especificado no seu .changes, exatamente, sem respeitar o que já está no arquivo. O arquivo pode muito bem rejeitar o seu envio.
Continua apesar do dgit não compreender o formato do seu pacote fonte. O dgit vai provavelmente trata-lo de maneira errada.
Não verifica se .dsc e .changes correspondem. O arquivo vai provavelmente rejeitar o seu envio.
Força ligar ou desligar do uso da emulação absurda git-apply quando corre gbp pq import ao importar um pacote a partir dum .dsc. Veja bug Debian #841867.
Continua e tenta empurrar mesmo que objetos git contaminados fizeram o servidor dizer que vai ser rejeitado, mas sem declarar nenhum --deliberately. Esta opção é fornecida para testes ou situações estranhas, e não é maneira de sobrepor a verificação de contaminação: usa-la irá provavelmente apenas falhar mais tarde, queimando o número de versão que está a usar. Use a opção --deliberately apropriada em vez disto.
Sobrepõe a definição de configuração dgit-distro.distro.readonly, para especificar que temos acesso leitura/escrita e deve usar o git correspondente e alcançar abordagem de acesso mesmo que a operação seja uma de só-leitura.
Especifica se deve-se tentar obter os artefactos do arquivo em falta a partir do espelho de recurso da distribuição. (Para Debian, o espelho de recurso é https://incoming.debian.org/debian-buildd/.)

A predefinição é tentar o espelho de recurso.

Especifica que a máquina que invoca dgit rpush deve estar disposta a assinar apenas um ficheiro .dsc ou .changes com suite alvo suite.
Especifica que a máquina que invoca dgit rpush deve estar disposta a assinar apenas um ficheiro .dsc ou .changes com versão versão.
Estas opções ativam mudanças de configuração e comportamento necessárias quando o robot tag2upload invoca o dgit. Elas não são destinadas a utilizadores.
Passa --allow-unrelated-histories ao comando git merge quando corre dgit pull. Isto torna o dgit pull mais fácil de usar quando o repositório principal nunca foi usado com dgit e por isso tem históricos não relacionados.
Adiciona um campo adicional de ficheiro controle ao .dsc.

Isto é semelhante a usar --dpkg-source:-DCAMPO=VALOR excepto que (1) você pode apenas adicionar um campo adicional, não sobrepor um valor, e (2) para um rpush, o campo é adicionado na máquina (assinando) que invoca, não na máquina que compila.

Como --dsc-control-add mas +para adicionar campos ao ficheiro .changes.

ESTADO DE SAÍDA

0
Sucesso.
3
Com dgit download-unfetched-origs, os origs relevantes foram identificados, mas alguns deles não puderam ser descarregados.
4
Pacote fonte não existe na suite requisitada.

Com dgit download-unfetched-origs, nenhuns origs relevantes existem no arquivo.

5
Com dgit download-unfetched-origs, a seleção de origs no arquivo é confusa: existem múltiplos ficheiros (para o mesmo componente), assim não conseguimos identificar exclusivamente qual deles usar.
6
Discrepância entre pacote fonte (gerado) e informação git. Veja dgit(7).

Quando dgit build-source termina com estado 6, o pacote fonte *foi* compilado; apenas pode não ser o que era pretendido.

8
Má utilização.
12
Configuração inválida.
Falha catastrófica.

CONFIGURAÇÃO

O dgit pode ser configurado via sistema de configuração do git. Você pode definir chaves com git-config (seja configuração global-do-sistema ou por-árvore), ou fornecer -cchave=valor na linha de comandos do dgit.

Definições que deverão ser usadas por utilizador final incluem:

Especifica onde encontrar os ficheiros de compilação para serem enviados, quando, --build-products-dir não é especificado. A predefinição é o directório pai (..).
Especifica a distribuição para uma suite. Chaves dgit fora do nome da suite (que aparecem em relatórios de alterações e etc.), e usa isso para determinar a distribuição que está envolvida. A configuração usada é a partir daí para a distribuição.

suite pode ser um padrão global.

A distribuição predefinida para uma suite desconhecida.

Isto é usado apenas se nenhum /usr/share/distro-info/alguma-distribuição.csv mencionar a suite especificada.

A suite predefinida (por exemplo para clone)
Para cada dgit-distro.distro.*, o valor predefinido usado se não existir uma definição específica de distribuição.
Se dgit build-source deve verificar que o pacote fonte resultante corresponde apropriadamente ao CABEÇALHO git. Verdadeiro por predefinição. (A verificação de correspondência não pode ser desativada para dgit push!, pois isso ia levar à publicação de resultados quebrados.)
Um dos valores para a linha de comandos --clean= opção; usado se --clean não for especificado.
Como .clean-mode, mas ignorado se o valor for desconhecido para esta versão do dgit. Definir ambos .clean-mode e .clean-mode-newer é útil para fornecer uma configuração git única compatível com diferentes versões do dgit.
Um dos valores para a linha de comandos --quilt= opção; usado se --quilt não for especificado.
Booleano, usado se nem --rm-old-changes nem --no-rm-old-changes for especificado. A predefinição é não remover.
Se você tem acesso de empurrar para a distribuição. Para Debian, é OK usar auto, o que usa modo só-leitura se você não está a empurrar no momento; mas, definir isto para false irá evitar depender do espelho do servidor de repositório git do dgit.
Veja também -k.
Não relevante para Debian.
Pode ser útil se você tiver um servidor de fila intermediária.
Valores a configurar para user.name e user.email em novas árvores git. Se não especificado, as variáveis de ambiente DEBFULLNAME e DEBEMAIL são usadas, respetivamente. Apenas usado se .setup-usermail não estiver desativado.
Se deve-se definir user.name e user.email em novas árvores git. Verdadeiro por predefinição. Ignorado para dgit setup-useremail, o que já o faz de qualquer maneira.
Se deve-se configurar um controlador de fusão que usa dpkg-mergechangelogs para debian/changelog. Verdadeiro por predefinição. Ignorado para dgit setup-mergechangelogs, o que já o faz de qualquer maneira.
Se deve-se configurar .git/info/attributes para suprimir transformações de conteúdo no ficheiro checkin/checkout em novas árvores git. Verdadeiro por predefinição. Ignorado para dgit setup-gitattributes, que já o faz de qualquer maneira.
Programa a usar em vez de cmd. Funciona como --cmd=... .
Opções extra a passar para cmd. Funciona como --cmd:... . Para passar várias opções, configure múltiplos valores na configuração do git (com git config --add). As opções para dgit.default.opts-cmd e dgit-distro.distro/push.opts-cmd são todas usadas, seguidas por opções da linha de comandos do dgit.

CONFIGURAÇÃO DE ACESSO

Existem muitas outras definições que especificam como os serviços duma distribuição particular (arquivo e git) são fornecidos. Estes não devem ser normalmente ajustados, mas estão documentados para o benefício das distribuições que desejam adotar o dgit.

Mostrado em etiquetas git, campos Dgit, e mais do mesmo.
Usado para procura de configuração de acesso total.
Se definido, sobrepõe configuração não /push correspondente quando readonly=false, ou quando se empurra e readonly=auto.
dgit-distro.distro.dep14tag-verify true|false
Controla o comportamento de dgit push.

VARIÁVEIS DE AMBIENTE

Especifica um programa predefinido alternativo (e talvez argumentos) para usar em vez do ssh. DGIT_SSH é consultado primeiro e pode conter argumentos; se conter qualquer espaço em branco será passado à shell. GIT_SSH especifica apenas o programa; nenhum argumento pode ser especificado, assim o dgit interpreta-o do mesmo modo que o git faz. Veja também as opções --ssh= e --ssh: .
O utilizador.email git predefinido e utilizador.nome para novas árvores. Veja dgit setup-new-tree.
e outros subprogramas e módulos usados pelo dgit são afetados por várias variáveis de ambiente. Consulte a documentação para esses programas para mais detalhes.

SUPORTE EM DISTRIBUIÇÕES ANTIGAS

Nós visamos fazer o dgit moderno instalável e utilizável em versões antigas de Debian, e nos derivados. Uma razão onde isto ajuda é que pode ser necessário atualizar para lidar com pacotes fonte estranhos que provocam bugs (no dgit ou em ferramentas que o dgit corre).

Esta versão de dgit.deb é diretamente instalável, e funcional (com apt install dgit.deb) andando para trás até Debian 10 (buster) e posteriores; isto é testado no nosso CI. É provável que funcione em muitos derivados de Debian também.

BUGS

Deverá existir um comando `dgit rebase-prep' ou algo do género para reverter um ramo de avanço rápido contendo pseudo-fusões de volta a uma pilha de patch re-baseada. Pode ter de deixar uma nota para um dgit push futuro.

Se o dgit push falhar a meio do caminho, não é necessariamente reiniciável e idempotente. Será bom verificar que a chave de assinatura proposta está disponível antes de começar o trabalho.

As funções de compilação do dgit, e o dgit push, podem fazer alterações no seu CABEÇALHO atual. Infelizmente isto é necessário para pacotes no formato fonte `3.0 (quilt)'. Isto deve-se ultimamente ao que Eu chamo de problemas de desenho no quilt e no dpkg-source.

--dry-run nem sempre funciona de modo apropriado, pois não fazer algumas das buscas git pode resultar em ações subsequentes a serem diferentes. Fazer um dgit fetch non-dry-run primeiro irá ajudar. --damp-run é provável que funcione muito melhor.

VEJA TAMBÉM

dgit(7), dgit-*(7), libcurl(3), dput(1), debsign(1), git-config(1), git-buildpackage(1), dpkg-buildpackage(1),
https://browse.dgit.debian.org/

Projeto Debian