What's the point of the Sign Off feature in Git?
git commit --signoff
When should I use it, if at all?
What's the point of the Sign Off feature in Git?
git commit --signoff
When should I use it, if at all?
Sign-off is a requirement for getting patches into the Linux kernel and a few other projects, but most projects don't actually use it.
It was introduced in the wake of the SCO lawsuit, (and other accusations of copyright infringement from SCO, most of which they never actually took to court), as a Developers Certificate of Origin. It is used to say that you certify that you have created the patch in question, or that you certify that to the best of your knowledge, it was created under an appropriate open-source license, or that it has been provided to you by someone else under those terms. This can help establish a chain of people who take responsibility for the copyright status of the code in question, to help ensure that copyrighted code not released under an appropriate free software (open source) license is not included in the kernel.
Sign-off is a line at the end of the commit message which certifies who is the author of the commit. Its main purpose is to improve tracking of who did what, especially with patches.
Example commit:
Add tests to statement printer.
Signed-off-by: Super Developer <super.dev@gmail.com>
It should contain the user real name if used for an open-source project.
If branch maintainer need to slightly modify patches in order to merge them, he could ask the submitter to rediff, but it would be counter-productive. He can adjust the code and put his sign-off at the end so the author still gets credit for the patch and not the introduced bugs.
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>
Source: http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html
git 2.7.1 (February 2016) clarifies that in commit b2c150d (05 Jan 2016) by David A. Wheeler (david-a-wheeler
).
(Merged by Junio C Hamano -- gitster
-- in commit 7aae9ba, 05 Feb 2016)
git commit
man page now includes:
-s::
--signoff::
Add
Signed-off-by
line by the committer at the end of the commit log message.
The meaning of a signoff depends on the project, but it typically certifies that committer has the rights to submit this work under the same license and agrees to a Developer Certificate of Origin (see https://developercertificate.org for more information).
Expand documentation describing
--signoff
Modify various document (man page) files to explain in more detail what
--signoff
means.This was inspired by "lwn article 'Bottomley: A modest proposal on the DCO'" (Developer Certificate of Origin) where paulj noted:
The issue I have with DCO is that there adding a "
-s
" argument to git commit doesn't really mean you have even heard of the DCO (thegit commit
man page makes no mention of the DCO anywhere), never mind actually seen it.So how can the presence of "
signed-off-by
" in any way imply the sender is agreeing to and committing to the DCO? Combined with fact I've seen replies on lists to patches without SOBs that say nothing more than "Resend this withsigned-off-by
so I can commit it".Extending git's documentation will make it easier to argue that developers understood
--signoff
when they use it.
Note that this signoff is now (for Git 2.15.x/2.16, Q1 2018) available for git pull
as well.
See commit 3a4d2c7 (12 Oct 2017) by W. Trevor King (wking
).
(Merged by Junio C Hamano -- gitster
-- in commit fb4cd88, 06 Nov 2017)
pull
: pass--signoff/--no-signoff
to "git merge
"merge can take
--signoff
, but without pull passing--signoff
down, it is inconvenient to use; allow 'pull
' to take the option and pass it through.
There are some nice answers on this question. I’ll try to add a more broad answer, namely about what these kinds of lines/headers/trailers are about in current practice. Not so much about the sign-off header in particular (it’s not the only one).
Headers or trailers (↑1) like “sign-off” (↑2) is, in current
practice in projects like Git and Linux, effectively structured metadata
for the commit. These are all appended to the end of the commit message,
after the “free form” (unstructured) part of the body of the message.
These are token–value (or key–value) pairs typically delimited by a
colon and a space (:␣
).
Like I mentioned, “sign-off” is not the only trailer in current practice. See for example this commit, which has to do with “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>
In addition to the “sign-off” trailer in the above, there is:
Other projects, like for example Gerrit, have their own headers and associated meaning for them.
See: https://git.wiki.kernel.org/index.php/CommitMessageConventions
It is my impression that, although the initial motivation for this particular metadata was some legal issues (judging by the other answers), the practice of such metadata has progressed beyond just dealing with the case of forming a chain of authorship.
[↑1]: man git-interpret-trailers
[↑2]: These are also sometimes called “s-o-b” (initials), it seems.