# [PATCH] Documentation: commit: explain the non-meaning of S-o-b 2 messages from 2009-12-28 to 2009-12-29. Participants: Jan Krüger, Junio C Hamano. Thread: https://gitlist.dev/t/22039 ## Jan Krüger, 2009-12-28 18:40 Subject: [PATCH] Documentation: commit: explain the non-meaning of S-o-b Message-ID: <20091228194001.7b4c68f4@perceptron> URL: https://gitlist.dev/e/20091228194001.7b4c68f4%40perceptron ``` In the manpage for git commit, the option --signoff is mentioned but there is no explanation of what it actually means. Add a brief hint that S-o-b doesn't have a pre-defined meaning. Signed-off-by: Jan Krüger --- Semi-resend. Nobody commented on this when I first sent it in early December, so here it is again, with a slightly more verbose explanation. The repetition is intentional. Documentation/git-commit.txt | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index d227cec..cae510b 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -114,7 +114,10 @@ OPTIONS -s:: --signoff:: Add Signed-off-by line by the committer at the end of the commit - log message. + log message. This line has no inherent meaning; it is up to the + potential recipient of the commit to decide what it stands for. + It is typically understood as an assurance by the committer that + the commit conforms to the receiving project's commit guidelines. -n:: --no-verify:: -- 1.6.5.3.171.ge36e ``` ## Junio C Hamano, 2009-12-29 07:54 Subject: Re: [PATCH] Documentation: commit: explain the non-meaning of S-o-b Message-ID: <7voclimd08.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7voclimd08.fsf%40alter.siamese.dyndns.org In-Reply-To: <20091228194001.7b4c68f4@perceptron> ``` Jan Krüger writes: > In the manpage for git commit, the option --signoff is mentioned but > there is no explanation of what it actually means. Add a brief hint that > S-o-b doesn't have a pre-defined meaning. The commands am, cherry-pick, commit, format-patch, and revert all share the "sign-off" and they more or less deliberately refused to define what it means to sign-off a patch; as your patch says, it is up to the project policy. config.txt gives a description for format.signoff option that is too specific to git and the kernel, which I think is a mistake given the much wider audience we have these days. How similar should the document for the "sign-off" options to these commands be? I am wondering if we should have the same description copied and pasted to all of them, or avoid repeating ourselves and instead have them refer to a central place, perhaps somewhere in the Tutorial or the Workflow document. > Signed-off-by: Jan Krüger > --- > Semi-resend. Nobody commented on this when I first sent it in early > December, so here it is again, with a slightly more verbose > explanation. The repetition is intentional. > > Documentation/git-commit.txt | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt > index d227cec..cae510b 100644 > --- a/Documentation/git-commit.txt > +++ b/Documentation/git-commit.txt > @@ -114,7 +114,10 @@ OPTIONS > -s:: > --signoff:: > Add Signed-off-by line by the committer at the end of the commit > - log message. > + log message. This line has no inherent meaning; it is up to the > + potential recipient of the commit to decide what it stands for. > + It is typically understood as an assurance by the committer that > + the commit conforms to the receiving project's commit guidelines. > > -n:: > --no-verify:: > -- > 1.6.5.3.171.ge36e ```