Respuestas:
El cierre de sesión es un requisito para obtener parches en el kernel de Linux y algunos otros proyectos, pero la mayoría de los proyectos en realidad no lo usan.
Se introdujo a raíz de la demanda de SCO (y otras acusaciones de infracción de derechos de autor de SCO , la mayoría de las cuales nunca se llevaron a los tribunales), como un Certificado de origen de desarrolladores . Se utiliza para decir que certifica que ha creado el parche en cuestión, o que certifica que, según su leal saber y entender, fue creado bajo una licencia de código abierto apropiada, o que alguien se lo ha proporcionado. más bajo esos términos. Esto puede ayudar a establecer una cadena de personas que asuman la responsabilidad del estado de copyright del código en cuestión, para ayudar a garantizar que el código protegido por derechos de autor no publicado bajo una licencia de software libre (código abierto) apropiado no esté incluido en el núcleo.
El cierre de sesión es una línea al final del mensaje de confirmación que certifica quién es el autor de la confirmación. Su objetivo principal es mejorar el seguimiento de quién hizo qué, especialmente con parches.
Ejemplo commit:
Add tests for the payment processor.
Signed-off-by: Humpty Dumpty <humpty.dumpty@example.com>
Debe contener el nombre real del usuario si se usa para un proyecto de código abierto.
Si el responsable de la sucursal necesita modificar ligeramente los parches para fusionarlos, podría pedirle al remitente que vuelva a enviar, pero sería contraproducente. Puede ajustar el código y poner su cierre de sesión al final para que el autor original todavía reciba crédito por el parche.
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>
Fuente: http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html
authorcampo de un git commit? Siempre pensé que por eso había una por separado authory committercampo. El autor es el escritor del parche y el confirmador es el que aplicó y presionó el parche.
git 2.7.1 (febrero de 2016) aclara que en commit b2c150d (05 de enero de 2016) por David A. Wheeler ( david-a-wheeler) .
(Fusionada por Junio C Hamano - gitster- en commit 7aae9ba , 05 feb 2016)
git commitLa página man ahora incluye:
-s::
--signoff::
Agregue
Signed-off-bylínea por el confirmador al final del mensaje de registro de confirmación.
El significado de una firma depende del proyecto, pero por lo general certifica que el responsable tiene los derechos para enviar este trabajo bajo la misma licencia y acepta un Certificado de origen del desarrollador (consulte https://developercertificate.org para obtener más información).
Ampliar la documentación que describe
--signoffModifique varios archivos de documentos (página de manual) para explicar con más detalle lo que
--signoffsignifica.Esto se inspiró en el " artículo de lwn 'Bottomley: una modesta propuesta sobre el DCO' " (Certificado de origen del desarrollador) donde Paulul señaló:
El problema que tengo con DCO es que agregar un "
-s" argumento a git commit no significa que hayas oído hablar del DCO ( lagit commitpágina del manual no menciona el DCO en ninguna parte ), no importa verlo realmente.Entonces, ¿cómo puede la presencia de "
signed-off-by" de alguna manera implicar que el remitente acepta y se compromete con el DCO? Combinado con el hecho, he visto respuestas en listas a parches sin SOB que dicen nada más que "Reenviar estosigned-off-bypara que pueda confirmarlo".Extender la documentación de git hará que sea más fácil argumentar que los desarrolladores entendieron
--signoffcuándo lo usan.
Tenga en cuenta que esta firma ahora también está disponible (para Git 2.15.x / 2.16, Q1 2018) git pull.
Ver commit 3a4d2c7 (12 de octubre de 2017) por W. Trevor King ( wking) .
(Fusionada por Junio C Hamano - gitster- en commit fb4cd88 , 06 nov 2017)
pull: pase--signoff/--no-signoffa "git merge"la fusión puede tomar
--signoff, pero sin tirar--signoffhacia abajo, es incómodo de usar; permitir 'pull' para tomar la opción y pasarla.
Hay algunas buenas respuestas a esta pregunta. Trataré de agregar una respuesta más amplia, a saber, de qué se trata este tipo de líneas / encabezados / trailers en la práctica actual. No se trata tanto del encabezado de cierre de sesión en particular (no es el único).
Los encabezados o trailers (↑ 1) como "cierre de sesión" (↑ 2) son, en la práctica actual en proyectos como Git y Linux, metadatos efectivamente estructurados para el commit. Todos estos se agregan al final del mensaje de confirmación, después de la parte de "forma libre" (no estructurada) del cuerpo del mensaje. Estos son pares token-value (o key-value ) típicamente delimitados por dos puntos y un espacio ( :␣).
Como mencioné, "cerrar sesión" no es el único avance en la práctica actual. Ver por ejemplo este commit , que tiene que ver con "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>
Además del trailer de "cierre de sesión" en lo anterior, hay:
Otros proyectos, como por ejemplo Gerrit, tienen sus propios encabezados y significado asociado para ellos.
Ver: https://git.wiki.kernel.org/index.php/CommitMessageConventions
Tengo la impresión de que, aunque la motivación inicial para estos metadatos en particular fueron algunos problemas legales (a juzgar por las otras respuestas), la práctica de dichos metadatos ha progresado más allá de solo tratar el caso de formar una cadena de autoría.
[↑ 1]: man git-interpret-trailers
[↑ 2]: Parece que a veces también se les llama "sollozo" (iniciales).
Signed-off-by:líneas de mensaje de confirmación por el proyecto del kernel de Linux (y el propio proyecto Git). Para otros proyectos, sin embargo, estas líneas no tienen sentido a menos que los cesionarios de proyectos que significan para ellos (por ejemplo, mediante la descripción de ellos en la documentación del proyecto, por ejemplo, de Linux SubmittingPatches o de Git SubmittingPatches ).