Para que serve o recurso Sign Off no Git?

Question

Qual é o objetivo do Recurso de assinatura no Git?

git commit --signoff

Quando devo usá-lo, se é que devo usá-lo?

Answer 1

A assinatura é um requisito para colocar patches no kernel Linux e em alguns outros projetos, mas a maioria dos projetos não o usa.

Foi introduzido após Processo SCO, (e Outras acusações de violação de direitos autorais da SCO, a maioria dos quais eles nunca realmente levaram ao tribunal), como um Desenvolvedores Certificado de Origem. É usado para dizer que você certifica que criou o patch em questão ou que certifica isso da melhor maneira possível, ele foi criado sob uma licença de código aberto apropriado ou que foi fornecido a você por alguém mais nesses termos. Isso pode ajudar a estabelecer uma cadeia de pessoas que assumem a responsabilidade pelo status de direitos autorais do código em questão, para ajudar a garantir que o código protegido por direitos autorais não seja liberado sob uma licença de software livre (código aberto) apropriado não esteja incluído no kernel.

Answer 2

A assinatura é uma linha no final da mensagem de confirmação que certifica quem é o autor da confirmação. Seu principal objetivo é melhorar o rastreamento de quem fez o que, especialmente com patches.

Exemplo de confirmação:

Add tests to statement printer.

Signed-off-by: Super Developer <super.dev@gmail.com>

Ele deve conter o nome real do usuário se usado para um projeto de código aberto.

Se o mantenedor da filial precisar modificar ligeiramente os patches para mesclá-los, ele poderia pedir ao enviado para rediff, mas seria contraproducente. Ele pode ajustar o código e colocar sua assinatura no final, para que o autor ainda obtenha crédito pelo patch e não pelos bugs introduzidos.

Add tests to statement printer.

Signed-off-by: Super Developer <super.dev@gmail.com>

[uber.dev@gmail.com: Renamed test methods according to naming convention.]
Signed-off-by: Uber Developer <uber.dev@gmail.com>

Fonte: http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html

Answer 3

git 2.7.1 (fevereiro de 2016) esclarece que em confirmar b2c150d (05 de janeiro de 2016) por Davi A.Roda (david-a-wheeler).
^{(Mesclado por Júnio C Hamano-- gitster -- em cometer 7aae9ba, 05 de fevereiro de 2016)}

git commit página de manual agora inclui:

-s::
--signoff::

Adicionar Signed-off-by linha pelo committer no final da mensagem de log de commit.
O significado de uma aprovação depende do projeto, mas normalmente certifica que o committer tem o direito de enviar este trabalho sob a mesma licença e concorda com um Certificado de Origem do Desenvolvedor (ver https://developercertificate.org Para maiores informações).

---

Expanda a documentação descrevendo --signoff

Modifique vários arquivos de documentos (páginas de manual) para explicar com mais detalhes o que --signoff significa.

Isso foi inspirado em "artigo lwn 'Bottomley:Uma proposta modesta sobre o DCO'" (Certificado de Origem do Desenvolvedor) onde paulj observou:

O problema que tenho com o DCO é que há adicionando um "-s"O argumento para git commit não significa que você já ouviu falar do DCO (o git commit A página de manual não faz menção ao DCO em lugar nenhum), não importa realmente ter visto.

Então, como pode a presença de "signed-off-by"de alguma forma implica que o remetente está concordando e se comprometendo com o DCO?Combinado com o fato, vi respostas em listas de patches sem SOBs que não dizem nada além de "Reenvie isto com signed-off-by para que eu possa cometê-lo".

Estender a documentação do git tornará mais fácil argumentar que os desenvolvedores entenderam --signoff quando eles o usam.

---

Observe que esta aprovação agora está (para Git 2.15.x/2.16, primeiro trimestre de 2018) disponível para git pull também.

Ver cometer 3a4d2c7 (12 de outubro de 2017) por C.Trevor Rei (wking).
^{(Mesclado por Júnio C Hamano-- gitster -- em cometer fb4cd88, 06 de novembro de 2017)}

pull:passar --signoff/--no-signoff para "git merge"

mesclar pode levar --signoff, mas sem puxar passagem --signoff Para baixo, é inconveniente de usar;permitir 'pull'Para tomar a opção e passar por ela.

Answer 4

Existem algumas boas respostas nesta pergunta. Vou tentar adicionar uma resposta mais ampla, a saber, sobre o que se trata esses tipos de linhas/cabeçalhos/reboques na prática atual. Não tanto sobre o cabeçalho de assinatura em particular (não é o único).

Cabeçalhos ou trechos de um filme (↑ 1) Como “assinatura” (↑ 2) está, na prática atual em projetos como Git e Linux, efetivamente estruturados metadados para o comprometimento. Tudo isso é anexado ao final da mensagem de confirmação, após a parte "Free Form" (não estruturada) da parte do corpo da mensagem. Estes são Token -Value (ou valor chave) pares normalmente delimitados por um cólon e um espaço (:␣).

Como mencionei, "assinar" não é o único trailer na prática atual. Veja, por exemplo este comprometimento, que tem a ver com "vaca suja":

 mm: remove gup_flags FOLL_WRITE games from __get_user_pages()
 This is an ancient bug that was actually attempted to be fixed once
 (badly) by me eleven years ago in commit 4ceb5db9757a ("Fix
 get_user_pages() race for write access") but that was then undone due to
 problems on s390 by commit f33ea7f404e5 ("fix get_user_pages bug").

 In the meantime, the s390 situation has long been fixed, and we can now
 fix it by checking the pte_dirty() bit properly (and do it better).  The
 s390 dirty bit was implemented in abf09bed3cce ("s390/mm: implement
 software dirty bits") which made it into v3.9.  Earlier kernels will
 have to look at the page state itself.

 Also, the VM has become more scalable, and what used a purely
 theoretical race back then has become easier to trigger.

 To fix it, we introduce a new internal FOLL_COW flag to mark the "yes,
 we already did a COW" rather than play racy games with FOLL_WRITE that
 is very fundamental, and then use the pte dirty flag to validate that
 the FOLL_COW flag is still valid.

 Reported-and-tested-by: Phil "not Paul" Oester <kernel@linuxace.com>
 Acked-by: Hugh Dickins <hughd@google.com>
 Reviewed-by: Michal Hocko <mhocko@suse.com>
 Cc: Andy Lutomirski <luto@kernel.org>
 Cc: Kees Cook <keescook@chromium.org>
 Cc: Oleg Nesterov <oleg@redhat.com>
 Cc: Willy Tarreau <w@1wt.eu>
 Cc: Nick Piggin <npiggin@gmail.com>
 Cc: Greg Thelen <gthelen@google.com>
 Cc: stable@vger.kernel.org
 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Além do trailer de "assinatura" acima, há:

• "CC" (foi notificado sobre o patch)
• “ACKED-BY” (reconhecido pelo proprietário do código, “parece bom para mim”)
• "Revisado por" revisado)
• "Relatado e testado" (relatado e testou o problema (presumo))

Outros projetos, como por exemplo, Gerrit, têm seus próprios cabeçalhos e significado associado para eles.

Ver: https://git.wiki.kernel.org/index.php/commitmessageConventions

Moral da história

Tenho a impressão de que, embora a motivação inicial para esses metadados em particular tenha sido algumas questões legais (a julgar pelas outras respostas), a prática de tais metadados progrediu além de apenas lidar com o caso de formar uma cadeia de autoria.

[↑1]: man git-interpret-trailers
↑ 2]: Eles também são chamados de "SOB" (iniciais), ao que parece.