NOME

       dgit-nmu-simple - tutorial para DDs que querem fazer NMU com o git

INTRODUÇÃO E ESCOPO

       This tutorial describes how a Debian Developer can do a straightforward NMU of a package in Debian,
       working (only) in git.

       Este documento não vai ajuda-lo a decidir se um NMU é uma boa ideia ou se vai ser bem recebido.  O
       Referência a Desenvolvedores Debian tem algumas orientações sobre isto (por vezes questionáveis).

       Por outro lado, você não precisa de saber nada sobre o normal fluxo de trabalho git dos maintainers.  Se
       for apropriado, você pode trabalhar em muitos pacotes diferentes, fazendo alterações semelhantes, sem se
       preocupar com as práticas git individuais dos maintainers.

       Este tutorial apenas cobre alterações que podem ser expressadas sensivelmente como um pequeno número
       razoável de cometeres lineares (seja para empacotamento Debian ou para ficheiros do autor ou ambos).

       Se você deseja fazer uma nova versão de autor, vai provavelmente querer fazer como o maintainer teria
       feito.  Você precisa de descobrir quais são as práticas git do maintainer e consultar o tutorial de fluxo
       de trabalho "dgit-maint-*(7)" apropriado.

SUMÁRIO

           % dgit clone glibc bookworm
           % cd glibc
           % git am ~/glibc-security-fix.diff
           % dch --nmu "Apply upstream's fix for foo bug."
           % git add debian/changelog && git commit -m"NMU changelog entry"
           % dpkg-buildpackage -uc -b
           [ correr os seus testes ]
           % dch -r && git add debian/changelog && git commit -m"Finalise NMU"
           % dgit -wgf sbuild -A -d trixie
           [ quaisquer testes finais nos .debs gerados ]
           % dgit -wgf [--delayed=5] push-source bookworm
           [ insira a sua frase-passe gnupg quando pedida ]
           [ veja se o empurrar e o envio tiveram sucesso ]
           [ prepare e envie email do diff do NMU (git-diff, git-format-patch) ]

QUE TIPO DE ALTERAÇÕES E COMETERES A FAZER

       Quando preparar um NMU, o cometer de git que fizer no ramo dgit deve ser uma série de cometeres lineares
       simples com boas mensagens do cometido.  As mensagens do cometido irão ser publicadas de várias maneiras,
       incluindo talvez serem usadas como mensagens de capa para as patches quilt geradas.

       Não faça cometeres de fusão.  Não tente re-basear para deitar fora patches existentes - se precisar de
       reverter uma alteração que é realmente uma patch Debian, use git-revert.

       Se você precisar modificar uma patch Debian, faça um novo cometer que corrija o que precisa ser
       corrigido, e explique na mensagem do cometido qual patch deve ser esborrachada (talvez usando uma
       mensagem do cometido no formato "git rebase --autosquash -i").

       (É claro que se você tiver instruções específicas do maintainer, você pode seguir essas em vez destas.
       Mas o procedimento deste tutorial é legítimo para qualquer maintainer, no sentido que deve gerar um envio
       para o qual o maintainer não pode razoavelmente objetar.)

PREPARANDO E REVISANDO O RAMO LOCAL

       O ramo dgit/sid é um ramo git local normal que segue um ramo do autor (sintético).  Assim você pode
       livremente rescrever quaisquer cometidos que fez localmente e não os empurrou para lado nenhum, como é
       normal.

       Uma coisa que é esquisita é os cometeres "quilt fixup" (que aparecem se você fizer ex dgit sbuild).  Se
       você estiver a re-basear-los de todo, você pode e deve apenas larga-los; o dgit irá depois regenera-los
       conforme necessário.

       Tudo isto baseia-se num facto subjacente:

       O dgit não tem estado git invisível em nenhum lado.  Assim se você re-basear para fora o quilt fixup, e
       re-trabalhar o seu ramo, o seu ramo vai continuar bem porque parece-se tal como ficava se você apenas
       fizesse esses cometeres diretamente. (NB git-debrebase tem um estado fora-de-ramo esquisito.)

RAMOS RELEVANTES

       O dgit clone irá coloca-lo num ramo como "dgit/sid".  Existe um pseudo-remoto chamado "dgit" que também
       contém um ramo como "dgit/sid", então você faz coisas como "git diff dgit/dgit/sid" para ver as
       alterações que você fez.

MANTER A SUA ÁRVORE DE TRABALHO ORGANIZADA

       Não esqueça de fazer "git add" a quaisquer novos ficheiros que crie.  Caso contrário o git clean (que é
       requisitado com a opção "-wgf" na receita em cima) irá apaga-los.

       Muitas compilações de pacote deixam as árvores git sujas.  Assim, cometer antes de compilar.  Desse modo
       você pode usar "git reset --hard".

       Se você seguir esta abordagem não precisa de se preocupar com o sujar da compilação na árvore.  Também
       significa que não se preocupa com o alvo de limpeza do pacote, o que também está bem porque muitos alvos
       de limpeza de pacote estão estragados.

OUTROS RAMOS GIT

       O histórico git do dgit (visível com gitk e o log do git)  não está necessariamente relacionado com o
       histórico git do maintainer ou do autor (se existir).

       Se o maintainer publicitou um repositório git com Vcs-Git, o dgit irá configurar um remoto para ele,
       assim você pode fazer

           % git fetch vcs-git

       Você pode escolher alterações a partir de lá, por exemplo.  Note que o histórico git do maintainer pode
       não ser apropriado para usar com o dgit. Por exemplo, pode existir um ramo de patches-não-aplicadas ou
       até conter apenas um directório debian/.

ENVIAR PARA ATRASADO

       Você pode usar a opção --delayed do dgit para enviar para a fila de espera ATRASADA.  No entanto, você
       deve ler o aviso sobre esta opção em dgit(1).

VEJA TAMBÉM

       dgit(1), dgit(7), dgit-maint-*(7)

Debian Project                                dgit+tag2upload team                            dgit-nmu-simple(7)