Respostas:
A assinatura é um requisito para obter correções no kernel do Linux e em alguns outros projetos, mas a maioria dos projetos não o utiliza.
Foi introduzido na sequência do processo da SCO (e outras acusações de violação de direitos autorais da SCO , a maioria das quais eles nunca levaram a tribunal), como um Certificado de Origem para Desenvolvedores . Costuma-se dizer que você certifica que criou o patch em questão ou que, segundo o seu conhecimento, foi criado sob uma licença de código-fonte apropriado ou que foi fornecido a você por alguém mais sob esses 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 liberado sob uma licença apropriada de software livre (código aberto) não seja incluído no kernel.
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 for the payment processor.
Signed-off-by: Humpty Dumpty <humpty.dumpty@example.com>
Ele deve conter o nome real do usuário, se usado para um projeto de código aberto.
Se o mantenedor da ramificação precisar modificar levemente as correções para mesclá-las, ele poderá solicitar que o remetente faça o rediff, mas isso seria contraproducente. Ele pode ajustar o código e encerrar sua assinatura no final para que o autor original ainda receba o crédito pelo patch.
Add tests for the payment processor.
Signed-off-by: Humpty Dumpty <humpty.dumpty@example.com>
[Project Maintainer: Renamed test methods according to naming convention.]
Signed-off-by: Project Maintainer <project.maintainer@example.com>
Fonte: http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html
authorcampo de um commit do git? Eu sempre pensei que era por isso que havia um campo authore um committercampo separados . O autor é o autor do patch e o committer é o cara que aplicou e empurrou o patch.
O git 2.7.1 (fevereiro de 2016) esclarece que no commit b2c150d (05 de janeiro de 2016) por David A. Wheeler ( david-a-wheeler) .
(Mesclado por Junio C Hamano - gitster- no commit 7aae9ba , 05 de fevereiro de 2016)
git commitA página de manual agora inclui:
-s::
--signoff::
Adicione
Signed-off-bylinha pelo confirmador no final da mensagem de log de confirmação.
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 (consulte https://developercertificate.org para obter mais informações).
Expandir a documentação descrevendo
--signoffModifique vários arquivos de documentos (página de manual) para explicar em mais detalhes o que
--signoffsignifica.Isso foi inspirado no " artigo da lwn 'Bottomley: Uma proposta modesta sobre o DCO' " (Certificado de Origem do Desenvolvedor), onde paulj observou:
O problema que tenho com o DCO é que adicionar um
-sargumento " " ao git commit não significa que você tenha ouvido falar do DCO ( agit commitpágina de manual não menciona o DCO em nenhum lugar) ), independentemente de realmente ter visto.Então, como a presença de "
signed-off-by" de qualquer forma implica que o remetente está concordando e se comprometendo com o OCD? Combinado com o fato, vi respostas em listas de patches sem SOBs que dizem nada mais do que "Reenviar issosigned-off-bypara que eu possa confirmar".A extensão da documentação do git tornará mais fácil argumentar que os desenvolvedores entenderam
--signoffquando o usam.
Observe que agora esta aprovação (para o Git 2.15.x / 2.16, primeiro trimestre de 2018) também está disponível git pull.
Veja commit 3a4d2c7 (12 de outubro de 2017) por W. Trevor King ( wking) .
(Mesclado por Junio C Hamano - gitster- in commit fb4cd88 , 06 de novembro de 2017)
pull: passe--signoff/--no-signoffpara "git merge"a fusão pode demorar
--signoff, mas sem puxar a transmissão--signoff, é inconveniente de usar; permita que 'pull' escolha a opção e passe-a.
Existem algumas respostas legais sobre esta questão. Tentarei adicionar uma resposta mais ampla, a saber, sobre o que são esses tipos de linhas / cabeçalhos / trailers na prática atual. Não tanto sobre o cabeçalho de assinatura em particular (não é o único).
Cabeçalhos ou trailers (↑ 1) como "logoff" (↑ 2) são, na prática atual em projetos como Git e Linux, metadados efetivamente estruturados para o commit. Tudo isso é anexado ao final da mensagem de confirmação, após a parte "forma livre" (não estruturada) do corpo da mensagem. Estes são pares de valor de token (ou valor-chave ) normalmente delimitados por dois pontos e um espaço ( :␣).
Como mencionei, “assinar” não é o único trailer na prática atual. Veja, por exemplo, este commit , que tem a ver com "Dirty Cow":
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 "assinar" acima, há:
Outros projetos, como, por exemplo, a Gerrit, têm cabeçalhos próprios e significado associado a eles.
Veja: https://git.wiki.kernel.org/index.php/CommitMessageConventions
Tenho a impressão de que, embora a motivação inicial para esses metadados específicos tenha sido algumas questões legais (a julgar pelas outras respostas), a prática desses 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.
Signed-off-by:linhas de mensagem de confirmação pelo projeto do kernel Linux (e pelo próprio projeto Git). Para outros projectos, no entanto, essas linhas não têm significado, a menos que os cessionários do projecto significado para eles (por exemplo, descrevendo-os na documentação do projecto; por exemplo, de Linux SubmittingPatches ou de Git SubmittingPatches ).