[PATCH 0/1] Clarify and expand description of --signoff

[PATCH 0/1] Clarify and expand description of --signoff

[Bradley M. Kuhn]

As you know, it's rare that Conservancy offers specific patches upstream to
our member projects, but I've attached a patch that updates the documentation
regarding Signed-Off-By.

While the Git and Linux projects use this specifically to refer to a DCO as
published on the URL provided, other projects have various meanings of
Signed-Off-By, and we noticed in a recent check of Conservancy member
projects that details on it vary.  Ultimately, I don't think Git wants anyway
to opine about the meaning of Signed-off-by for every project that uses Git,
so this documentation change hedges while still explaning and recommending
the DCO used by Linux and Git.

Peff gave me some feedback on this change and we did a bit of redrafting in a
private email thread, but I think this is now ready for public review and
discussion.

I apologize in advance if I've made a mistake in format or form in submitting
this patch; it's my first upstream contribution to Git!  I did try my best to
follow Documentation/MyFirstContribution.txt carefully! :)

Bradley M. Kuhn (1):
  Documentation: Clarify and expand description of --signoff

 Documentation/git-commit.txt    | 13 ++++++++-----
 Documentation/merge-options.txt | 13 ++++++++-----
 2 files changed, 16 insertions(+), 10 deletions(-)

-- 
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter

[PATCH 1/1] Documentation: Clarify and expand description of --signoff

[Bradley M. Kuhn]

Building on past documentation improvements in Commit
b2c150d3aa (Expand documentation describing --signoff, 2016-01-05),
further clarify that any project using Git may and often does set its
own policy.

However, leave intact reference to the Linux DCO, which Git also
uses.  It is reasonable for Git to advocate for its own Signed-off-by
methodology in its documentation, as long as the documentation
remains respectful that YMMV and other projects may well have very
different contributor representations tied to Signed-off-by.

Signed-off-by: Bradley M. Kuhn <bkuhn@sfconservancy.org>
---
 Documentation/git-commit.txt    | 13 ++++++++-----
 Documentation/merge-options.txt | 13 ++++++++-----
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index a3baea32ae..93bbae4ded 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -166,11 +166,14 @@ The `-m` option is mutually exclusive with `-c`, `-C`, and `-F`.
 -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 http://developercertificate.org/ for more information).
+	log message.  The meaning of a signoff depends on the project to which
+	you're committing.  For example, it may certify that the committer has
+	the rights to submit the work under the project's license or agrees to
+	some contributor representation, such as a Developer Certificate of
+	Origin.  (See http://developercertificate.org for the one used by the
+	Linux kernel and Git projects.)  Consult the documentation or
+	leadership of the project to which you're contributing to understand
+	how the signoffs are used in that project.
 
 -n::
 --no-verify::
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 80d4831662..c9df9cc0f4 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -80,11 +80,14 @@ actual commits being merged.
 --signoff::
 --no-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 http://developercertificate.org/ for more information).
+	log message.  The meaning of a signoff depends on the project to which
+	you're committing.  For example, it may certify that the committer has
+	the rights to submit the work under the project's license or agrees to
+	some contributor representation, such as a Developer Certificate of
+	Origin.  (See http://developercertificate.org for the one used by the
+	Linux kernel and Git projects.)  Consult the documentation or
+	leadership of the project to which you're contributing to understand
+	 how the signoffs are used in that project.
 +
 With --no-signoff do not add a Signed-off-by line.
 
-- 
2.26.1

Re: [PATCH 1/1] Documentation: Clarify and expand description of --signoff

[Jeff King]

On Thu, Oct 15, 2020 at 02:59:33PM -0700, Bradley M. Kuhn wrote:

> Building on past documentation improvements in Commit
> b2c150d3aa (Expand documentation describing --signoff, 2016-01-05),
> further clarify that any project using Git may and often does set its
> own policy.
> 
> However, leave intact reference to the Linux DCO, which Git also
> uses.  It is reasonable for Git to advocate for its own Signed-off-by
> methodology in its documentation, as long as the documentation
> remains respectful that YMMV and other projects may well have very
> different contributor representations tied to Signed-off-by.

I think this is worth doing, and doesn't really change the intent of
what we were trying to do with b2c150d3aa. It just says it a bit more
clearly, IMHO.

Except for one minor nit below, the patch looks good to me.
Unsurprisingly, since as you mentioned we discussed it off-list
already. :)

To be clear, it's...

  Signed-off-by: Jeff King <peff@peff.net>

as far as any words I contributed.

As far as your patch formatting, submission, etc, it looks OK. I
probably would've kept "clarify" in the title as lowercase. I'd also
usually not do a separate cover letter for a single-patch series (and
instead put anything not meant for the commit message after the "---"
line). But that's mostly a matter of taste (a lot of people do separate
cover letters).

> diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
> index 80d4831662..c9df9cc0f4 100644
> --- a/Documentation/merge-options.txt
> +++ b/Documentation/merge-options.txt
> [...]
> +	leadership of the project to which you're contributing to understand
> +	 how the signoffs are used in that project.

Extra leading space on this final line.

-Peff

PS Since this is your first patch submission, welcome to the Git
   project. ;)

Re: [PATCH 0/1] Clarify and expand description of --signoff

[Philippe Blain]

Hi Bradley, 

> Le 15 oct. 2020 à 17:59, Bradley M. Kuhn <bkuhn@sfconservancy.org> a écrit :
> 
> 
> Documentation/git-commit.txt    | 13 ++++++++-----
> Documentation/merge-options.txt | 13 ++++++++-----
> 2 files changed, 16 insertions(+), 10 deletions(-)

Since the changes are exactly the same in the two files, maybe
a preparatory patch that creates 'signoff.txt' and includes it
in 'git-commit.txt' and 'merge-options.txt' would be a good idea ?

Cheers,

Philippe.

Re: [PATCH 0/1] Clarify and expand description of --signoff

[Junio C Hamano]

> > Documentation/git-commit.txt    | 13 ++++++++-----
> > Documentation/merge-options.txt | 13 ++++++++-----
> > 2 files changed, 16 insertions(+), 10 deletions(-)
>
> Since the changes are exactly the same in the two files, maybe
> a preparatory patch that creates 'signoff.txt' and includes it
> in 'git-commit.txt' and 'merge-options.txt' would be a good idea ?

I actually think we are OK with two duplicated and leave that for
later clean-up. The more important would be to polish the text into
a good enough state quickly.

Another thing we should not forget is to update our SubmittingPatches
document. Since we are placing extra stress on that there is NO
inherent meaning in "sign off" and it is largely up to each project,
we should set a good example explaining what it means to THIS
project to sign your patches off, and SubmittingPatches is the
document to do so. Without such an update, I think the update
to these two files we see in this patch is incomplete.

Thanks.

Re: [PATCH 0/1] Clarify and expand description of --signoff

[Jeff King]

On Thu, Oct 15, 2020 at 06:54:30PM -0700, Junio C Hamano wrote:

> > > Documentation/git-commit.txt    | 13 ++++++++-----
> > > Documentation/merge-options.txt | 13 ++++++++-----
> > > 2 files changed, 16 insertions(+), 10 deletions(-)
> >
> > Since the changes are exactly the same in the two files, maybe
> > a preparatory patch that creates 'signoff.txt' and includes it
> > in 'git-commit.txt' and 'merge-options.txt' would be a good idea ?
> 
> I actually think we are OK with two duplicated and leave that for
> later clean-up. The more important would be to polish the text into
> a good enough state quickly.
> 
> Another thing we should not forget is to update our SubmittingPatches
> document. Since we are placing extra stress on that there is NO
> inherent meaning in "sign off" and it is largely up to each project,
> we should set a good example explaining what it means to THIS
> project to sign your patches off, and SubmittingPatches is the
> document to do so. Without such an update, I think the update
> to these two files we see in this patch is incomplete.

I agree we should be leading by example here.

We do already say pretty clearly what signed-off-by means in the
project:

  $ grep -A14 '\[\[sign-off]]' Documentation/SubmittingPatches 
  [[sign-off]]
  === Certify your work by adding your "Signed-off-by: " line
  
  To improve tracking of who did what, we've borrowed the
  "sign-off" procedure from the Linux kernel project on patches
  that are being emailed around.  Although core Git is a lot
  smaller project it is a good discipline to follow it.
  
  The sign-off is a simple line at the end of the explanation for
  the patch, which certifies that you wrote it or otherwise have
  the right to pass it on as an open-source patch.  The rules are
  pretty simple: if you can certify the below D-C-O:
  
  [[dco]]
  .Developer's Certificate of Origin 1.1

What should we change there? We could perhaps bring up signoffs earlier
or more prominently. Or tie it in to the git-commit docs by saying
explicitly: these are _our_ project rules for signoffs.

-Peff

Re: [PATCH 0/1] Clarify and expand description of --signoff

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> We do already say pretty clearly what signed-off-by means in the
> project:
>
>   $ grep -A14 '\[\[sign-off]]' Documentation/SubmittingPatches 
>   [[sign-off]]
>   === Certify your work by adding your "Signed-off-by: " line
>   
>   To improve tracking of who did what, we've borrowed the
>   "sign-off" procedure from the Linux kernel project on patches
>   that are being emailed around.  Although core Git is a lot
>   smaller project it is a good discipline to follow it.
>   
>   The sign-off is a simple line at the end of the explanation for
>   the patch, which certifies that you wrote it or otherwise have
>   the right to pass it on as an open-source patch.  The rules are
>   pretty simple: if you can certify the below D-C-O:
>   
>   [[dco]]
>   .Developer's Certificate of Origin 1.1
>
> What should we change there? We could perhaps bring up signoffs earlier
> or more prominently. Or tie it in to the git-commit docs by saying
> explicitly: these are _our_ project rules for signoffs.

That is almost good enough, but you can easily see that it was
written back when the world only had choice between "Linux-style
signed-off-by that means Linux-style DCO requirement" and "not
signing off", and we chose to be in the former camp.

I think the most important clarification Bradley's making is that we
no longer live in such a world.  "signed-off-by" means different
things for different projects, and what we use is this one.  That
choice may have been adopted from the Linux project and may have
been identical to what they used back when we adopted it, but that
is of secondary importance (most importantly, if they changed what
it means, that won't directly affect this project).

Perhaps I'd rewrite these two paragraphs like so:

    To improve tracking of who did what, we use the "sign off"
    procedure.  By adding the "Signed-off-by:" line in the trailer
    of your commit, you certify to this project the below D-C-O that
    you have the right to pass your patch on under the same license
    as ours.  Without such a sign-off, we cannot accept your patch:

    [[dco]]
    .Developer's Certificate of Origin 1.1

    ...

and after the DCO text, add this paragraph as a historical reference.

    This procedure originally came from the Linux kernel project, so
    our rule is quite similar to theirs, but what exactly it means
    to sign-off your patch differs from project to project, so it
    may be different from that of the project you are accustomed to.

either before or after the "Random J Developer" example.  I think we
should remove the "you can do this automatically by giving -s" or at
least the word "automatically" from that sentence, while we are at
it.

Thanks.

Re: [PATCH 0/1] Clarify and expand description of --signoff

[Junio C Hamano]

> Jeff King <peff@peff.net> writes:
>
>> What should we change there? We could perhaps bring up signoffs earlier
>> or more prominently. Or tie it in to the git-commit docs by saying
>> explicitly: these are _our_ project rules for signoffs.

Let's tie this loose end.  How about squashing in something like
this?

-- >8 --
Subject: SubmittingPatches: clarify DCO is our --signoff rule

The description on sign-off and DCO was written back in the days
where there was only a choice between "use sign-off and it means the
contributor agrees to the Linux-kernel style DCO" and "not using
sign-off at all will make your patch unusable".  These days, we are
trying to clarify that the exact meaning of a sign-off varies
project to project.

Let's be more explicit when presenting what _our_ rules are.  It is
of secondary importance that it originally came from the kernel
project, so move the description as a historical note at the end,
while cautioning that what a sign-off means to us may be different from
what it means to other projects contributors may have been used to.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/SubmittingPatches | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git c/Documentation/SubmittingPatches w/Documentation/SubmittingPatches
index 291b61e262..f83a050b35 100644
--- c/Documentation/SubmittingPatches
+++ w/Documentation/SubmittingPatches
@@ -300,15 +300,12 @@ patch.
 [[sign-off]]
 === Certify your work by adding your "Signed-off-by: " line
 
-To improve tracking of who did what, we've borrowed the
-"sign-off" procedure from the Linux kernel project on patches
-that are being emailed around.  Although core Git is a lot
-smaller project it is a good discipline to follow it.
+To improve tracking of who did what, we ask you to certify that you
+wrote the patch or have the right to pass it on under the same license
+as ours, by "signing off" your patch.  Without sign-off, we cannot
+accept your patches.
 
-The sign-off is a simple line at the end of the explanation for
-the patch, which certifies that you wrote it or otherwise have
-the right to pass it on as an open-source patch.  The rules are
-pretty simple: if you can certify the below D-C-O:
+If you can certify the below D-C-O:
 
 [[dco]]
 .Developer's Certificate of Origin 1.1
@@ -338,14 +335,15 @@ d. I understand and agree that this project and the contribution
    this project or the open source license(s) involved.
 ____
 
-then you just add a line saying
+you add a "Signed-off-by" trailer to your commit, that looks like
+this:
 
 ....
 	Signed-off-by: Random J Developer <random@developer.example.org>
 ....
 
-This line can be automatically added by Git if you run the git-commit
-command with the -s option.
+This line can be added by Git if you run the git-commit command with
+the -s option.
 
 Notice that you can place your own Signed-off-by: line when
 forwarding somebody else's patch with the above rules for
@@ -353,6 +351,11 @@ D-C-O.  Indeed you are encouraged to do so.  Do not forget to
 place an in-body "From: " line at the beginning to properly attribute
 the change to its true author (see (2) above).
 
+This procedure originally came from the Linux kernel project, so our
+rule is quite similar to theirs, but what exactly it means to sign-off
+your patch differs from project to project, so it may be different
+from that of the project you are accustomed to.
+
 [[real-name]]
 Also notice that a real name is used in the Signed-off-by: line. Please
 don't hide your real name.

Re: [PATCH 0/1] Clarify and expand description of --signoff

[Jeff King]

On Fri, Oct 16, 2020 at 12:53:56PM -0700, Junio C Hamano wrote:

> > Jeff King <peff@peff.net> writes:
> >
> >> What should we change there? We could perhaps bring up signoffs earlier
> >> or more prominently. Or tie it in to the git-commit docs by saying
> >> explicitly: these are _our_ project rules for signoffs.
> 
> Let's tie this loose end.  How about squashing in something like
> this?

Thanks for writing this up. I agree it makes the text much better (not
only in emphasizing the point we've been discussing, but also in general
clarity).

You said "squashing", but I'd suggest keeping it as its own patch on top
of Bradley's.

-Peff

Re: [PATCH 0/1] Clarify and expand description of --signoff

[Bradley M. Kuhn]

Jeff King wrote:
> You said "squashing", but I'd suggest keeping it as its own patch on top
> of Bradley's.

While I admit a certain vain desire to have my name appear in Git's own
commit history (given that it's unlikely I'll ever be able to spare the time
to make another contribution), if it's cleaner to squash my change, I can
assent to that and you can consider both patches discussed in this thread
together:

  Signed-off-by: Bradley M. Kuhn <bkuhn@sfconservancy.org>

--
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter

Re: [PATCH 1/1] Documentation: Clarify and expand description of --signoff

[Theodore Y. Ts'o]

On Thu, Oct 15, 2020 at 02:59:33PM -0700, Bradley M. Kuhn wrote:
> diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
> index a3baea32ae..93bbae4ded 100644
> --- a/Documentation/git-commit.txt
> +++ b/Documentation/git-commit.txt
> @@ -166,11 +166,14 @@ The `-m` option is mutually exclusive with `-c`, `-C`, and `-F`.
>  -s::
>  --signoff::
>  	Add Signed-off-by line by the committer at the end of the commit

While we're editing this, how about changing the above to read:

	Add a Signed-off-by line...

to fix a grammer nit.  We do use a similar formulation later the git
merge-options man page:

>  With --no-signoff do not add a Signed-off-by line.


> diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
> index 80d4831662..c9df9cc0f4 100644
> --- a/Documentation/merge-options.txt
> +++ b/Documentation/merge-options.txt
> @@ -80,11 +80,14 @@ actual commits being merged.
>  --signoff::
>  --no-signoff::
>  	Add Signed-off-by line by the committer at the end of the commit

... and again here.

Thanks!

					- Ted

Re: [PATCH 0/1] Clarify and expand description of --signoff

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Fri, Oct 16, 2020 at 12:53:56PM -0700, Junio C Hamano wrote:
>
>> > Jeff King <peff@peff.net> writes:
>> >
>> >> What should we change there? We could perhaps bring up signoffs earlier
>> >> or more prominently. Or tie it in to the git-commit docs by saying
>> >> explicitly: these are _our_ project rules for signoffs.
>> 
>> Let's tie this loose end.  How about squashing in something like
>> this?
>
> Thanks for writing this up. I agree it makes the text much better (not
> only in emphasizing the point we've been discussing, but also in general
> clarity).
>
> You said "squashing", but I'd suggest keeping it as its own patch on top
> of Bradley's.

OK, let's do so.

I recall I read that Bradley's patch needs a bit of word/grammo
polishing?

Thanks.

[PATCH v2 0/3] Claryfing the meaning of the sign-off

[Junio C Hamano]

So here is to tie the loose ends, based on inputs to the first
round.

 * [1/3] is new; this is a preparatory clean-up to dedup two very
   similar paragraphs in the existing documentation, thanks to the
   idea by Philippe Blain.

 * [2/3] is text taken from Bradley's patch to update the manpages;
   thanks to the preparatory clean-up, we no longer need to
   duplicate the new text.  Grammofix pointed out by Ted Ts'o has
   also been applied.

 * [3/3] clarifies what sign-off means to _this_ project.  This step
   hasn't changed from what has been queued in 'seen'.

For those who missed the original, it appears at 

    lore.kernel.org/git/20201015215933.96425-1-bkuhn@sfconservancy.org

Bradley M. Kuhn (1):
  Documentation: clarify and expand description of --signoff

Junio C Hamano (2):
  doc: preparatory clean-up of description on the sign-off option
  SubmittingPatches: clarify DCO is our --signoff rule

 Documentation/SubmittingPatches  | 25 ++++++++++++++-----------
 Documentation/git-commit.txt     | 10 ++--------
 Documentation/merge-options.txt  | 11 +----------
 Documentation/signoff-option.txt | 18 ++++++++++++++++++
 4 files changed, 35 insertions(+), 29 deletions(-)
 create mode 100644 Documentation/signoff-option.txt

[PATCH v2 1/3] doc: preparatory clean-up of description on the sign-off option

[Junio C Hamano]

Almost identical text on the signed-off-by trailer appears in the
documentation for "git commit" and "git merge" and its friends.

Introduce a new signoff-options.txt file to be shared.  A couple
things of note are:

 - The short-form "-s" is available only in "git commit", but not in
   commands that are friends of "git merge", as it is used as a
   short-hand for "--strategy".

 - The original lacks description on the negated "--no-signoff" form
   on "git commit" side, but it equally is applicable.  It however
   was unclear in the original text that not adding a Signed-off-by
   trailer is the default, so rephrase to explain it as a way to
   countermand a --signoff option that appeared earlier on the same
   command line.

This is in preparation to apply a further clarification on what
exactly the Signed-off-by trailer means.

Suggested-by: Philippe Blain <levraiphilippeblain@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 * It initially seemed that the update in [v2 2/3] didn't need too
   many iterations to complete, but it turned out that a preliminary
   clean-up would make it easier to iterate on the text after all.

 Documentation/git-commit.txt     | 10 ++--------
 Documentation/merge-options.txt  | 11 +----------
 Documentation/signoff-option.txt | 14 ++++++++++++++
 3 files changed, 17 insertions(+), 18 deletions(-)
 create mode 100644 Documentation/signoff-option.txt

diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index a3baea32ae..17150fa7ea 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -59,6 +59,7 @@ commit by giving the same set of parameters (options and paths).
 If you make a commit and then find a mistake immediately after
 that, you can recover from it with 'git reset'.
 
+:git-commit: 1
 
 OPTIONS
 -------
@@ -163,14 +164,7 @@ The `-m` option is mutually exclusive with `-c`, `-C`, and `-F`.
 	message, the commit is aborted.  This has no effect when a message
 	is given by other means, e.g. with the `-m` or `-F` options.
 
--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 http://developercertificate.org/ for more information).
+include::signoff-option.txt[]
 
 -n::
 --no-verify::
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 80d4831662..eb0aabd396 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -77,16 +77,7 @@ When not possible, refuse to merge and exit with a non-zero status.
 With --no-log do not list one-line descriptions from the
 actual commits being merged.
 
---signoff::
---no-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 http://developercertificate.org/ for more information).
-+
-With --no-signoff do not add a Signed-off-by line.
+include::signoff-option.txt[]
 
 --stat::
 -n::
diff --git a/Documentation/signoff-option.txt b/Documentation/signoff-option.txt
new file mode 100644
index 0000000000..d1c6713774
--- /dev/null
+++ b/Documentation/signoff-option.txt
@@ -0,0 +1,14 @@
+ifdef::git-commit[]
+-s::
+endif::git-commit[]
+--signoff::
+--no-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 http://developercertificate.org/ for more information).
++
+The --no-signoff option can be used to countermand an earlier --signoff
+option on the command line.
-- 
2.29.0-rc2-130-g9dc1ca14f3

[PATCH v2 2/3] Documentation: clarify and expand description of --signoff

[Junio C Hamano]

From: "Bradley M. Kuhn" <bkuhn@sfconservancy.org>

Building on past documentation improvements in b2c150d3aa (Expand
documentation describing --signoff, 2016-01-05), further clarify
that any project using Git may and often does set its own policy.

However, leave intact reference to the Linux DCO, which Git also
uses.  It is reasonable for Git to advocate for its own Signed-off-by
methodology in its documentation, as long as the documentation
remains respectful that YMMV and other projects may well have very
different contributor representations tied to Signed-off-by.

Signed-off-by: Bradley M. Kuhn <bkuhn@sfconservancy.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/signoff-option.txt | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/Documentation/signoff-option.txt b/Documentation/signoff-option.txt
index d1c6713774..fbff8dd5be 100644
--- a/Documentation/signoff-option.txt
+++ b/Documentation/signoff-option.txt
@@ -3,12 +3,16 @@ ifdef::git-commit[]
 endif::git-commit[]
 --signoff::
 --no-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 http://developercertificate.org/ for more information).
+	Add a Signed-off-by trailer by the committer at the end of the commit
+	log message.  The meaning of a signoff depends on the project
+	to which you're committing.  For example, it may certify that
+	the committer has the rights to submit the work under the
+	project's license or agrees to some contributor representation,
+	such as a Developer Certificate of Origin.
+	(See http://developercertificate.org for the one used by the
+	Linux kernel and Git projects.)  Consult the documentation or
+	leadership of the project to which you're contributing to
+	understand how the signoffs are used in that project.
 +
 The --no-signoff option can be used to countermand an earlier --signoff
 option on the command line.
-- 
2.29.0-rc2-130-g9dc1ca14f3

[PATCH v2 3/3] SubmittingPatches: clarify DCO is our --signoff rule

[Junio C Hamano]

The description on sign-off and DCO was written back in the days
where there was only a choice between "use sign-off and it means the
contributor agrees to the Linux-kernel style DCO" and "not using
sign-off at all will make your patch unusable".  These days, we are
trying to clarify that the exact meaning of a sign-off varies
project to project.

Let's be more explicit when presenting what _our_ rules are.  It is
of secondary importance that it originally came from the kernel
project, so move the description as a historical note at the end,
while cautioning that what a sign-off means to us may be different from
what it means to other projects contributors may have been used to.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/SubmittingPatches | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 291b61e262..f83a050b35 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -300,15 +300,12 @@ patch.
 [[sign-off]]
 === Certify your work by adding your "Signed-off-by: " line
 
-To improve tracking of who did what, we've borrowed the
-"sign-off" procedure from the Linux kernel project on patches
-that are being emailed around.  Although core Git is a lot
-smaller project it is a good discipline to follow it.
+To improve tracking of who did what, we ask you to certify that you
+wrote the patch or have the right to pass it on under the same license
+as ours, by "signing off" your patch.  Without sign-off, we cannot
+accept your patches.
 
-The sign-off is a simple line at the end of the explanation for
-the patch, which certifies that you wrote it or otherwise have
-the right to pass it on as an open-source patch.  The rules are
-pretty simple: if you can certify the below D-C-O:
+If you can certify the below D-C-O:
 
 [[dco]]
 .Developer's Certificate of Origin 1.1
@@ -338,14 +335,15 @@ d. I understand and agree that this project and the contribution
    this project or the open source license(s) involved.
 ____
 
-then you just add a line saying
+you add a "Signed-off-by" trailer to your commit, that looks like
+this:
 
 ....
 	Signed-off-by: Random J Developer <random@developer.example.org>
 ....
 
-This line can be automatically added by Git if you run the git-commit
-command with the -s option.
+This line can be added by Git if you run the git-commit command with
+the -s option.
 
 Notice that you can place your own Signed-off-by: line when
 forwarding somebody else's patch with the above rules for
@@ -353,6 +351,11 @@ D-C-O.  Indeed you are encouraged to do so.  Do not forget to
 place an in-body "From: " line at the beginning to properly attribute
 the change to its true author (see (2) above).
 
+This procedure originally came from the Linux kernel project, so our
+rule is quite similar to theirs, but what exactly it means to sign-off
+your patch differs from project to project, so it may be different
+from that of the project you are accustomed to.
+
 [[real-name]]
 Also notice that a real name is used in the Signed-off-by: line. Please
 don't hide your real name.
-- 
2.29.0-rc2-130-g9dc1ca14f3

Re: [PATCH v2 0/3] Claryfing the meaning of the sign-off

[Taylor Blau]

Hi Junio,

On Sun, Oct 18, 2020 at 12:49:09PM -0700, Junio C Hamano wrote:
> So here is to tie the loose ends, based on inputs to the first
> round.

All of this looks very good to me, and I really appreciate 1/3, since it
made reviewing 2/3 much easier (the combination of seeing more-or-less
the same diff twice combined with the re-wrapping made it tricky to
read, at least for me).

  Reviewed-by: Taylor Blau <me@ttaylorr.com>

Thanks,
Taylor

Re: [PATCH 0/1] Clarify and expand description of --signoff

[Theodore Y. Ts'o]

On Sun, Oct 18, 2020 at 12:08:15PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
> 
> > On Fri, Oct 16, 2020 at 12:53:56PM -0700, Junio C Hamano wrote:
> >
> >> > Jeff King <peff@peff.net> writes:
> >> >
> >> >> What should we change there? We could perhaps bring up signoffs earlier
> >> >> or more prominently. Or tie it in to the git-commit docs by saying
> >> >> explicitly: these are _our_ project rules for signoffs.
> >> 
> >> Let's tie this loose end.  How about squashing in something like
> >> this?
> >
> > Thanks for writing this up. I agree it makes the text much better (not
> > only in emphasizing the point we've been discussing, but also in general
> > clarity).
> >
> > You said "squashing", but I'd suggest keeping it as its own patch on top
> > of Bradley's.
> 
> OK, let's do so.
> 
> I recall I read that Bradley's patch needs a bit of word/grammo
> polishing?

Well, I pointed out a missing article ("a") in the line *above*
Bradley's change in two man pages.  It's a minor nit, and it's
unrelated to his proposed change.  I have no opinion about whether
it's better to do it separately from his change or as a separate
commit.

						- Ted

Re: [PATCH 0/1] Clarify and expand description of --signoff

[Junio C Hamano]

"Theodore Y. Ts'o" <tytso@mit.edu> writes:

>> > You said "squashing", but I'd suggest keeping it as its own patch on top
>> > of Bradley's.
>> 
>> OK, let's do so.
>> 
>> I recall I read that Bradley's patch needs a bit of word/grammo
>> polishing?
>
> Well, I pointed out a missing article ("a") in the line *above*
> Bradley's change in two man pages.  It's a minor nit, and it's
> unrelated to his proposed change.  I have no opinion about whether
> it's better to do it separately from his change or as a separate
> commit.

Thanks for reminding me.  In any case, an updated version that ended
up being a 3-patch series is now on the table.  I think they are in
good shape to be merged down.

Thanks.

[PATCH v2 0/3] clarify and expand description of --signoff & related fixes

[Bradley M. Kuhn]

Jeff wrote last week:
>>> You said "squashing", but I'd suggest keeping it as its own patch on top
>>> of Bradley's.
Junio replied last week:
>> OK, let's do so.
Theodore Ts'o wrote today at 08:53 (PDT):
>>>> I pointed out a missing article ("a") in the line *above* ... It's a
>>>> minor nit, and it's unrelated to his proposed change.
Junio C Hamano replied today at 11:26 (PDT):
> In any case, an updated version that ended up
> being a 3-patch series is now on the table.  I think they are in good
> shape to be merged down.

Herein is (I believe) the three-patch series that Junio references.  The
middle patch didn't exist yet because Ted just pointed out the typo and
didn't have a patch, but I've done the typo fix and credited Ted on that in
the commit.

However, the middle commit ([PATCH v2 2/3]) needs some review.  I ended up
down the rabbit hole of "what is the consistent way in which the Git
documentation refers to Signed-off-by?" and I found many inconsistencies.
I've normalized around a style convention described in that patch's commit
message.

Meanwhile, I also note that SubmittingPatches now calls these "trailers"
rather than "lines", so maybe we should be using the word "trailer" rather
than "line" consistently in the other documentation?  If folks think that
should be done, I can redo this patchset to go that route.

Alternatively, if anyone has any strong opinions on the normalization to:
  (a|the) `Signed-off-by:` line
in documentation formatting when referring to Signed-off-by, please say so.

Thanks everyone for your comments and help on this!

I also added these, as Jeff King wrote about at 17:46 (PDT) on Thursday:
>>> To be clear, it's...
>>>  Signed-off-by: Jeff King <peff@peff.net>
>>> as far as any words I contributed.

Added.

>>> I probably would've kept "clarify" in the title as lowercase.

Fixed.

>>>>> diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
>>>>> index 80d4831662..c9df9cc0f4 100644
>>>>> --- a/Documentation/merge-options.txt
>>>>> +++ b/Documentation/merge-options.txt
>>>>> [...]
>>>>> +	leadership of the project to which you're contributing to understand
>>>>> +	 how the signoffs are used in that project.

>>> Extra leading space on this final line.

Also fixed.

Bradley M. Kuhn (2):
  Documentation: clarify and expand description of --signoff
  Documentation: stylistically normalize references to Signed-off-by:

Junio C Hamano (1):
  SubmittingPatches: clarify DCO is our --signoff rule

 Documentation/MyFirstContribution.txt |  2 +-
 Documentation/SubmittingPatches       | 35 +++++++++++++++------------
 Documentation/git-cherry-pick.txt     |  2 +-
 Documentation/git-commit.txt          | 15 +++++++-----
 Documentation/git-format-patch.txt    |  2 +-
 Documentation/git-rebase.txt          |  2 +-
 Documentation/git-revert.txt          |  2 +-
 Documentation/git-send-email.txt      |  4 +--
 Documentation/githooks.txt            |  2 +-
 Documentation/merge-options.txt       | 17 +++++++------
 builtin/am.c                          |  2 +-
 builtin/commit.c                      |  2 +-
 builtin/log.c                         |  2 +-
 builtin/merge.c                       |  2 +-
 builtin/pull.c                        |  2 +-
 builtin/revert.c                      |  2 +-
 16 files changed, 52 insertions(+), 43 deletions(-)

-- 
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter

[PATCH v2 1/3] Documentation: clarify and expand description of --signoff

[Bradley M. Kuhn]

Building on past documentation improvements in Commit
b2c150d3aa (Expand documentation describing --signoff, 2016-01-05),
further clarify that any project using Git may and often does set its
own policy.

However, leave intact reference to the Linux DCO, which Git also
uses.  It is reasonable for Git to advocate for its own Signed-off-by
methodology in its documentation, as long as the documentation
remains respectful that YMMV and other projects may well have very
different contributor representations tied to Signed-off-by.

Signed-off-by: Bradley M. Kuhn <bkuhn@sfconservancy.org>
Signed-off-by: Jeff King <peff@peff.net>
---
 Documentation/git-commit.txt    | 13 ++++++++-----
 Documentation/merge-options.txt | 13 ++++++++-----
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index a3baea32ae..93bbae4ded 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -166,11 +166,14 @@ The `-m` option is mutually exclusive with `-c`, `-C`, and `-F`.
 -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 http://developercertificate.org/ for more information).
+	log message.  The meaning of a signoff depends on the project to which
+	you're committing.  For example, it may certify that the committer has
+	the rights to submit the work under the project's license or agrees to
+	some contributor representation, such as a Developer Certificate of
+	Origin.  (See http://developercertificate.org for the one used by the
+	Linux kernel and Git projects.)  Consult the documentation or
+	leadership of the project to which you're contributing to understand
+	how the signoffs are used in that project.
 
 -n::
 --no-verify::
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 80d4831662..29e6030131 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -80,11 +80,14 @@ actual commits being merged.
 --signoff::
 --no-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 http://developercertificate.org/ for more information).
+	log message.  The meaning of a signoff depends on the project to which
+	you're committing.  For example, it may certify that the committer has
+	the rights to submit the work under the project's license or agrees to
+	some contributor representation, such as a Developer Certificate of
+	Origin.  (See http://developercertificate.org for the one used by the
+	Linux kernel and Git projects.)  Consult the documentation or
+	leadership of the project to which you're contributing to understand
+	how the signoffs are used in that project.
 +
 With --no-signoff do not add a Signed-off-by line.
 
-- 
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter

[PATCH v2 2/3] Documentation: stylistically normalize references to Signed-off-by:

[Bradley M. Kuhn]

Ted reported during patch review of the previous commit that an old
typo was present in the git-commit.txt and merge-options.txt.
Namely, the phrase "Signed-off-by line" was used without either a
definite nor indefinite article.

Upon examination, it seems that the documentation (including items in
Documentation/, but also option help strings) have been quite
inconsistent on usage when referring to `Signed-off-by:`.

It seems the original usage, seen in Commit
3f971fc425b (Documentation updates, 2005-08-14) initially used "Add
Signed-off-by line", and Commit 6f855371a53 (Add --signoff, --check,
and long option-names. 2005-12-09) switched to using "Add
`Signed-off-by:` line", but didn't normalize the former commit to
match.  Later commits seem to have cut and pasted from one or the
other, which is likely how the usage became so inconsistent.

Very few places used a definite or indefinite article with the phrase
"Signed-off-by: line", but that was the initial typo that led me down
this investigation, so I have normalized using either an indefinite
or definite article consistently.  Since usage of
`Signed-off-by:` (with the colon) was about six months more current
than without the colon, I chose `Signed-off-by:` (with backticks) for
the documentation files and Signed-off-by: (without backticks) for
option help strings

I left alone a few places in documentation that used the phrase
Signed-off-by (without colon or backticks) to refer to the
process (rather than the specific line), and I also left alone one
place where many mail headers were mentioned in a specific way so the
style for Signed-off-by and those mail headers remained consistent.

Reported-by: "Theodore Y. Ts'o" <tytso@mit.edu>
Message-ID: <20201018151315.GJ181507@mit.edu>
Signed-off-by: Bradley M. Kuhn <bkuhn@sfconservancy.org>
---
 Documentation/MyFirstContribution.txt |  2 +-
 Documentation/SubmittingPatches       | 10 +++++-----
 Documentation/git-cherry-pick.txt     |  2 +-
 Documentation/git-commit.txt          |  2 +-
 Documentation/git-format-patch.txt    |  2 +-
 Documentation/git-rebase.txt          |  2 +-
 Documentation/git-revert.txt          |  2 +-
 Documentation/git-send-email.txt      |  4 ++--
 Documentation/githooks.txt            |  2 +-
 Documentation/merge-options.txt       |  4 ++--
 builtin/am.c                          |  2 +-
 builtin/commit.c                      |  2 +-
 builtin/log.c                         |  2 +-
 builtin/merge.c                       |  2 +-
 builtin/pull.c                        |  2 +-
 builtin/revert.c                      |  2 +-
 16 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt
index 4f85a089ef..9a7f76cdef 100644
--- a/Documentation/MyFirstContribution.txt
+++ b/Documentation/MyFirstContribution.txt
@@ -249,7 +249,7 @@ component you're working on, followed by a blank line (always required) and then
 the body of your commit message, which should provide the bulk of the context.
 Remember to be explicit and provide the "Why" of your change, especially if it
 couldn't easily be understood from your diff. When editing your commit message,
-don't remove the Signed-off-by line which was added by `-s` above.
+don't remove the `Signed-off-by:` line which was added by `-s` above.
 
 ----
 psuh: add a built-in by popular demand
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 291b61e262..d520eb23b1 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -209,7 +209,7 @@ send them as replies to either an additional "cover letter" message
 (see below), the first patch, or the respective preceding patch.
 
 If your log message (including your name on the
-Signed-off-by line) is not writable in ASCII, make sure that
+`Signed-off-by:` line) is not writable in ASCII, make sure that
 you send off a message in the correct encoding.
 
 WARNING: Be wary of your MUAs word-wrap
@@ -229,7 +229,7 @@ previously sent.
 The `git format-patch` command follows the best current practice to
 format the body of an e-mail message.  At the beginning of the
 patch should come your commit message, ending with the
-Signed-off-by: lines, and a line that consists of three dashes,
+`Signed-off-by:` lines, and a line that consists of three dashes,
 followed by the diffstat information and the patch itself.  If
 you are forwarding a patch from somebody else, optionally, at
 the beginning of the e-mail message just before the commit
@@ -298,7 +298,7 @@ Do not forget to add trailers such as `Acked-by:`, `Reviewed-by:` and
 patch.
 
 [[sign-off]]
-=== Certify your work by adding your "Signed-off-by: " line
+=== Certify your work by adding your `Signed-off-by:` line
 
 To improve tracking of who did what, we've borrowed the
 "sign-off" procedure from the Linux kernel project on patches
@@ -347,14 +347,14 @@ then you just add a line saying
 This line can be automatically added by Git if you run the git-commit
 command with the -s option.
 
-Notice that you can place your own Signed-off-by: line when
+Notice that you can place your own `Signed-off-by:` line when
 forwarding somebody else's patch with the above rules for
 D-C-O.  Indeed you are encouraged to do so.  Do not forget to
 place an in-body "From: " line at the beginning to properly attribute
 the change to its true author (see (2) above).
 
 [[real-name]]
-Also notice that a real name is used in the Signed-off-by: line. Please
+Also notice that a real name is used in the `Signed-off-by:` line. Please
 don't hide your real name.
 
 [[commit-trailers]]
diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index 75feeef08a..4b8e8bc484 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -104,7 +104,7 @@ effect to your index in a row.
 
 -s::
 --signoff::
-	Add Signed-off-by line at the end of the commit message.
+	Add a `Signed-off-by:` line at the end of the commit message.
 	See the signoff option in linkgit:git-commit[1] for more information.
 
 -S[<keyid>]::
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 93bbae4ded..8f0ff51237 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -165,7 +165,7 @@ The `-m` option is mutually exclusive with `-c`, `-C`, and `-F`.
 
 -s::
 --signoff::
-	Add Signed-off-by line by the committer at the end of the commit
+	Add a `Signed-off-by:` line by the committer at the end of the commit
 	log message.  The meaning of a signoff depends on the project to which
 	you're committing.  For example, it may certify that the committer has
 	the rights to submit the work under the project's license or agrees to
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 0f81d0437b..439c2cf461 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -119,7 +119,7 @@ include::diff-options.txt[]
 
 -s::
 --signoff::
-	Add `Signed-off-by:` line to the commit message, using
+	Add a `Signed-off-by:` line to the commit message, using
 	the committer identity of yourself.
 	See the signoff option in linkgit:git-commit[1] for more information.
 
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 38e15488f6..2ad5f9eadc 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -496,7 +496,7 @@ See also INCOMPATIBLE OPTIONS below.
 See also INCOMPATIBLE OPTIONS below.
 
 --signoff::
-	Add a Signed-off-by: trailer to all the rebased commits. Note
+	Add a `Signed-off-by:` trailer to all the rebased commits. Note
 	that if `--interactive` is given then only commits marked to be
 	picked, edited or reworded will have the trailer added.
 +
diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
index 044276e9da..e89359d4bd 100644
--- a/Documentation/git-revert.txt
+++ b/Documentation/git-revert.txt
@@ -99,7 +99,7 @@ effect to your index in a row.
 
 -s::
 --signoff::
-	Add Signed-off-by line at the end of the commit message.
+	Add a `Signed-off-by:` line at the end of the commit message.
 	See the signoff option in linkgit:git-commit[1] for more information.
 
 --strategy=<strategy>::
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 0a69810147..e9c0f22700 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -313,7 +313,7 @@ Automating
 	the value of `sendemail.identity`.
 
 --[no-]signed-off-by-cc::
-	If this is set, add emails found in Signed-off-by: or Cc: lines to the
+	If this is set, add emails found in the `Signed-off-by:` or Cc: lines to the
 	cc list. Default is the value of `sendemail.signedoffbycc` configuration
 	value; if that is unspecified, default to --signed-off-by-cc.
 
@@ -340,7 +340,7 @@ Automating
   except for self (use 'self' for that).
 - 'bodycc' will avoid including anyone mentioned in Cc lines in the
   patch body (commit message) except for self (use 'self' for that).
-- 'sob' will avoid including anyone mentioned in Signed-off-by lines except
+- 'sob' will avoid including anyone mentioned in the `Signed-off-by:` lines except
   for self (use 'self' for that).
 - 'misc-by' will avoid including anyone mentioned in Acked-by,
   Reviewed-by, Tested-by and other "-by" lines in the patch body,
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 6e461ace6e..5063b02ab6 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -164,7 +164,7 @@ can also be used to refuse the commit after inspecting the message
 file.
 
 The default 'commit-msg' hook, when enabled, detects duplicate
-"Signed-off-by" lines, and aborts the commit if one is found.
+`Signed-off-by:` lines, and aborts the commit if one is found.
 
 post-commit
 ~~~~~~~~~~~
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 29e6030131..0eed6a7bb2 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -79,7 +79,7 @@ actual commits being merged.
 
 --signoff::
 --no-signoff::
-	Add Signed-off-by line by the committer at the end of the commit
+	Add a `Signed-off-by:` line by the committer at the end of the commit
 	log message.  The meaning of a signoff depends on the project to which
 	you're committing.  For example, it may certify that the committer has
 	the rights to submit the work under the project's license or agrees to
@@ -89,7 +89,7 @@ actual commits being merged.
 	leadership of the project to which you're contributing to understand
 	how the signoffs are used in that project.
 +
-With --no-signoff do not add a Signed-off-by line.
+With --no-signoff do not add a `Signed-off-by:` line.
 
 --stat::
 -n::
diff --git a/builtin/am.c b/builtin/am.c
index 2c7673f74e..e13b121b76 100644
--- a/builtin/am.c
+++ b/builtin/am.c
@@ -2237,7 +2237,7 @@ int cmd_am(int argc, const char **argv, const char *prefix)
 			N_("allow fall back on 3way merging if needed")),
 		OPT__QUIET(&state.quiet, N_("be quiet")),
 		OPT_SET_INT('s', "signoff", &state.signoff,
-			N_("add a Signed-off-by line to the commit message"),
+			N_("add a Signed-off-by: line to the commit message"),
 			SIGNOFF_EXPLICIT),
 		OPT_BOOL('u', "utf8", &state.utf8,
 			N_("recode into utf8 (default)")),
diff --git a/builtin/commit.c b/builtin/commit.c
index 1dfd799ec5..6e254440f2 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1507,7 +1507,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
 		OPT_STRING(0, "fixup", &fixup_message, N_("commit"), N_("use autosquash formatted message to fixup specified commit")),
 		OPT_STRING(0, "squash", &squash_message, N_("commit"), N_("use autosquash formatted message to squash specified commit")),
 		OPT_BOOL(0, "reset-author", &renew_authorship, N_("the commit is authored by me now (used with -C/-c/--amend)")),
-		OPT_BOOL('s', "signoff", &signoff, N_("add Signed-off-by:")),
+		OPT_BOOL('s', "signoff", &signoff, N_("add a Signed-off-by: line")),
 		OPT_FILENAME('t', "template", &template_file, N_("use specified template file")),
 		OPT_BOOL('e', "edit", &edit_flag, N_("force edit of commit")),
 		OPT_CLEANUP(&cleanup_arg),
diff --git a/builtin/log.c b/builtin/log.c
index 0a7ed4bef9..615bd69baf 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1738,7 +1738,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
 		OPT_CALLBACK_F('N', "no-numbered", &numbered, NULL,
 			    N_("use [PATCH] even with multiple patches"),
 			    PARSE_OPT_NOARG | PARSE_OPT_NONEG, no_numbered_callback),
-		OPT_BOOL('s', "signoff", &do_signoff, N_("add Signed-off-by:")),
+		OPT_BOOL('s', "signoff", &do_signoff, N_("add a Signed-off-by: line")),
 		OPT_BOOL(0, "stdout", &use_stdout,
 			    N_("print patches to standard out")),
 		OPT_BOOL(0, "cover-letter", &cover_letter,
diff --git a/builtin/merge.c b/builtin/merge.c
index 9d5359edc2..5a2b4ca29e 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -289,7 +289,7 @@ static struct option builtin_merge_options[] = {
 	  N_("GPG sign commit"), PARSE_OPT_OPTARG, NULL, (intptr_t) "" },
 	OPT_AUTOSTASH(&autostash),
 	OPT_BOOL(0, "overwrite-ignore", &overwrite_ignore, N_("update ignored files (default)")),
-	OPT_BOOL(0, "signoff", &signoff, N_("add Signed-off-by:")),
+	OPT_BOOL(0, "signoff", &signoff, N_("add a Signed-off-by: line")),
 	OPT_BOOL(0, "no-verify", &no_verify, N_("bypass pre-merge-commit and commit-msg hooks")),
 	OPT_END()
 };
diff --git a/builtin/pull.c b/builtin/pull.c
index 425950f469..4d47fe5d3c 100644
--- a/builtin/pull.c
+++ b/builtin/pull.c
@@ -142,7 +142,7 @@ static struct option pull_options[] = {
 		N_("add (at most <n>) entries from shortlog to merge commit message"),
 		PARSE_OPT_OPTARG),
 	OPT_PASSTHRU(0, "signoff", &opt_signoff, NULL,
-		N_("add Signed-off-by:"),
+		N_("add a Signed-off-by: line"),
 		PARSE_OPT_OPTARG),
 	OPT_PASSTHRU(0, "squash", &opt_squash, NULL,
 		N_("create a single commit instead of doing a merge"),
diff --git a/builtin/revert.c b/builtin/revert.c
index f61cc5d82c..1c895efedd 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -107,7 +107,7 @@ static int run_sequencer(int argc, const char **argv, struct replay_opts *opts)
 		OPT_BOOL('n', "no-commit", &opts->no_commit, N_("don't automatically commit")),
 		OPT_BOOL('e', "edit", &opts->edit, N_("edit the commit message")),
 		OPT_NOOP_NOARG('r', NULL),
-		OPT_BOOL('s', "signoff", &opts->signoff, N_("add Signed-off-by:")),
+		OPT_BOOL('s', "signoff", &opts->signoff, N_("add a Signed-off-by: line")),
 		OPT_CALLBACK('m', "mainline", opts, N_("parent-number"),
 			     N_("select mainline parent"), option_parse_m),
 		OPT_RERERE_AUTOUPDATE(&opts->allow_rerere_auto),
-- 
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter

[PATCH v2 3/3] SubmittingPatches: clarify DCO is our --signoff rule

[Bradley M. Kuhn]

From: Junio C Hamano <gitster@pobox.com>

The description on sign-off and DCO was written back in the days
where there was only a choice between "use sign-off and it means the
contributor agrees to the Linux-kernel style DCO" and "not using
sign-off at all will make your patch unusable".  These days, we are
trying to clarify that the exact meaning of a sign-off varies
project to project.

Let's be more explicit when presenting what _our_ rules are.  It is
of secondary importance that it originally came from the kernel
project, so move the description as a historical note at the end,
while cautioning that what a sign-off means to us may be different from
what it means to other projects contributors may have been used to.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Bradley M. Kuhn <bkuhn@sfconservancy.org>
---
 Documentation/SubmittingPatches | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index d520eb23b1..b798aef844 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -300,15 +300,12 @@ patch.
 [[sign-off]]
 === Certify your work by adding your `Signed-off-by:` line
 
-To improve tracking of who did what, we've borrowed the
-"sign-off" procedure from the Linux kernel project on patches
-that are being emailed around.  Although core Git is a lot
-smaller project it is a good discipline to follow it.
+To improve tracking of who did what, we ask you to certify that you
+wrote the patch or have the right to pass it on under the same license
+as ours, by "signing off" your patch.  Without sign-off, we cannot
+accept your patches.
 
-The sign-off is a simple line at the end of the explanation for
-the patch, which certifies that you wrote it or otherwise have
-the right to pass it on as an open-source patch.  The rules are
-pretty simple: if you can certify the below D-C-O:
+If you can certify the below D-C-O:
 
 [[dco]]
 .Developer's Certificate of Origin 1.1
@@ -338,14 +335,15 @@ d. I understand and agree that this project and the contribution
    this project or the open source license(s) involved.
 ____
 
-then you just add a line saying
+you add a "Signed-off-by" trailer to your commit, that looks like
+this:
 
 ....
 	Signed-off-by: Random J Developer <random@developer.example.org>
 ....
 
-This line can be automatically added by Git if you run the git-commit
-command with the -s option.
+This line can be added by Git if you run the git-commit command with
+the -s option.
 
 Notice that you can place your own `Signed-off-by:` line when
 forwarding somebody else's patch with the above rules for
@@ -353,6 +351,11 @@ D-C-O.  Indeed you are encouraged to do so.  Do not forget to
 place an in-body "From: " line at the beginning to properly attribute
 the change to its true author (see (2) above).
 
+This procedure originally came from the Linux kernel project, so our
+rule is quite similar to theirs, but what exactly it means to sign-off
+your patch differs from project to project, so it may be different
+from that of the project you are accustomed to.
+
 [[real-name]]
 Also notice that a real name is used in the `Signed-off-by:` line. Please
 don't hide your real name.
-- 
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter

Re: [PATCH v2 2/3] Documentation: stylistically normalize references to Signed-off-by:

[Taylor Blau]

Hi Bradley,

I think that the 3-patch series that Junio was talking about in [1] is
actually this one [2].

Skimming the differences between the two, this patch of yours doesn't
have an analogue in what Junio sent. But, I think it's worthwhile, so
perhaps it could be applied on top before moving into next (at the time
of writing, this is integrated into 'seen' as 1b98087e0f (Merge
branch 'bk/sob-dco' into jch, 2020-10-19)).

On Mon, Oct 19, 2020 at 02:25:43PM -0700, Bradley M. Kuhn wrote:
> Ted reported during patch review of the previous commit that an old
> typo was present in the git-commit.txt and merge-options.txt.
> Namely, the phrase "Signed-off-by line" was used without either a
> definite nor indefinite article.
>
> [...]
>
> Reported-by: "Theodore Y. Ts'o" <tytso@mit.edu>
> Message-ID: <20201018151315.GJ181507@mit.edu>
> Signed-off-by: Bradley M. Kuhn <bkuhn@sfconservancy.org>

  Acked-by: Taylor Blau <me@ttaylorr.com>

Thanks,
Taylor

[1]: https://lore.kernel.org/git/xmqqmu0it6ls.fsf@gitster.c.googlers.com/
[2]: https://lore.kernel.org/git/20201018194912.2716372-1-gitster@pobox.com/

Re: [PATCH v2 2/3] Documentation: stylistically normalize references to Signed-off-by:

[Junio C Hamano]

Taylor Blau <me@ttaylorr.com> writes:

> I think that the 3-patch series that Junio was talking about in [1] is
> actually this one [2].
> ...
> [1]: https://lore.kernel.org/git/xmqqmu0it6ls.fsf@gitster.c.googlers.com/
> [2]: https://lore.kernel.org/git/20201018194912.2716372-1-gitster@pobox.com/

True.

I actually think it is a bad idea to add ":" after every mention of
"Signed-off-by"; it only looks clarifying because we use a boring
and generic word "line" to refer to where that three-word token
appears.

We can say "a 'Signed-off-by' trailer" and it becomes plenty clear
that we are not talking about any random line in the log message,
and we do not need ":" everywhere, I suspect.

Thanks.

[PATCH v3 0/4] clarify meaning of --signoff & related doc improvements in describing Signed-off-by

[Bradley M. Kuhn]

[ Note that there were competing v2's of this patch series, one from me and
  one from Junio.  Sorry about that; I had missed Junio's from Sunday. ]

I believe this patch series now addresses all the issues raised in the
discussion.

  * [1/4] is unchanged from Junio's v2 and is the preparatory cleanup.

  * [2/4] remains unchanged textually since I originally posted it and Pfeff
    signed off.

  * [3/4] is unchanged from Junio's v2 and is his clarification for what
     Git's --signoff means.
     
  * [4/4] is a rework of a patch from *my* v2.  It takes into account Junio's
    comments about preferring the word "trailer" and leaving off the ':'
    whenever possible when discussing Signed-off-by.

For reference:

        v1: https://lore.kernel.org/git/20201015215933.96425-1-bkuhn@sfconservancy.org/
Junio's v2: https://lore.kernel.org/git/20201018194912.2716372-1-gitster@pobox.com/
     my v2: https://lore.kernel.org/git/cover.1603142543.git.bkuhn@sfconservancy.org/

Bradley M. Kuhn (2):
  Documentation: clarify and expand description of --signoff
  Documentation: stylistically normalize references to Signed-off-by:

Junio C Hamano (2):
  doc: preparatory clean-up of description on the sign-off option
  SubmittingPatches: clarify DCO is our --signoff rule

 Documentation/MyFirstContribution.txt |  2 +-
 Documentation/SubmittingPatches       | 35 +++++++++++++++------------
 Documentation/config/format.txt       |  2 +-
 Documentation/git-am.txt              |  2 +-
 Documentation/git-cherry-pick.txt     |  2 +-
 Documentation/git-commit.txt          | 10 ++------
 Documentation/git-format-patch.txt    |  2 +-
 Documentation/git-rebase.txt          |  2 +-
 Documentation/git-revert.txt          |  2 +-
 Documentation/git-send-email.txt      |  4 +--
 Documentation/git-svn.txt             |  4 +--
 Documentation/githooks.txt            |  2 +-
 Documentation/merge-options.txt       | 11 +--------
 Documentation/signoff-option.txt      | 18 ++++++++++++++
 builtin/am.c                          |  2 +-
 builtin/commit.c                      |  2 +-
 builtin/log.c                         |  2 +-
 builtin/merge.c                       |  2 +-
 builtin/pull.c                        |  2 +-
 builtin/rebase.c                      |  2 +-
 builtin/revert.c                      |  2 +-
 commit.c                              |  2 +-
 22 files changed, 60 insertions(+), 54 deletions(-)
 create mode 100644 Documentation/signoff-option.txt

-- 
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter

[PATCH v3 1/4] doc: preparatory clean-up of description on the sign-off option

[Bradley M. Kuhn]

From: Junio C Hamano <gitster@pobox.com>

Almost identical text on the signed-off-by trailer appears in the
documentation for "git commit" and "git merge" and its friends.

Introduce a new signoff-options.txt file to be shared.  A couple
things of note are:

 - The short-form "-s" is available only in "git commit", but not in
   commands that are friends of "git merge", as it is used as a
   short-hand for "--strategy".

 - The original lacks description on the negated "--no-signoff" form
   on "git commit" side, but it equally is applicable.  It however
   was unclear in the original text that not adding a Signed-off-by
   trailer is the default, so rephrase to explain it as a way to
   countermand a --signoff option that appeared earlier on the same
   command line.

This is in preparation to apply a further clarification on what
exactly the Signed-off-by trailer means.

Suggested-by: Philippe Blain <levraiphilippeblain@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reviewed-by: Taylor Blau <me@ttaylorr.com>
Reviewed-by: Bradley M. Kuhn <bkuhn@sfconservancy.org>
---
 Documentation/git-commit.txt     | 10 ++--------
 Documentation/merge-options.txt  | 11 +----------
 Documentation/signoff-option.txt | 14 ++++++++++++++
 3 files changed, 17 insertions(+), 18 deletions(-)
 create mode 100644 Documentation/signoff-option.txt

diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index a3baea32ae..17150fa7ea 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -59,6 +59,7 @@ commit by giving the same set of parameters (options and paths).
 If you make a commit and then find a mistake immediately after
 that, you can recover from it with 'git reset'.
 
+:git-commit: 1
 
 OPTIONS
 -------
@@ -163,14 +164,7 @@ The `-m` option is mutually exclusive with `-c`, `-C`, and `-F`.
 	message, the commit is aborted.  This has no effect when a message
 	is given by other means, e.g. with the `-m` or `-F` options.
 
--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 http://developercertificate.org/ for more information).
+include::signoff-option.txt[]
 
 -n::
 --no-verify::
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 80d4831662..eb0aabd396 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -77,16 +77,7 @@ When not possible, refuse to merge and exit with a non-zero status.
 With --no-log do not list one-line descriptions from the
 actual commits being merged.
 
---signoff::
---no-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 http://developercertificate.org/ for more information).
-+
-With --no-signoff do not add a Signed-off-by line.
+include::signoff-option.txt[]
 
 --stat::
 -n::
diff --git a/Documentation/signoff-option.txt b/Documentation/signoff-option.txt
new file mode 100644
index 0000000000..d1c6713774
--- /dev/null
+++ b/Documentation/signoff-option.txt
@@ -0,0 +1,14 @@
+ifdef::git-commit[]
+-s::
+endif::git-commit[]
+--signoff::
+--no-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 http://developercertificate.org/ for more information).
++
+The --no-signoff option can be used to countermand an earlier --signoff
+option on the command line.
-- 
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter

[PATCH v3 2/4] Documentation: clarify and expand description of --signoff

[Bradley M. Kuhn]

Building on past documentation improvements in b2c150d3aa (Expand
documentation describing --signoff, 2016-01-05), further clarify
that any project using Git may and often does set its own policy.

However, leave intact reference to the Linux DCO, which Git also
uses.  It is reasonable for Git to advocate for its own Signed-off-by
methodology in its documentation, as long as the documentation
remains respectful that YMMV and other projects may well have very
different contributor representations tied to Signed-off-by.

Signed-off-by: Bradley M. Kuhn <bkuhn@sfconservancy.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jeff King <peff@peff.net>
Reviewed-by: Taylor Blau <me@ttaylorr.com>
---
 Documentation/signoff-option.txt | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/Documentation/signoff-option.txt b/Documentation/signoff-option.txt
index d1c6713774..fbff8dd5be 100644
--- a/Documentation/signoff-option.txt
+++ b/Documentation/signoff-option.txt
@@ -3,12 +3,16 @@ ifdef::git-commit[]
 endif::git-commit[]
 --signoff::
 --no-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 http://developercertificate.org/ for more information).
+	Add a Signed-off-by trailer by the committer at the end of the commit
+	log message.  The meaning of a signoff depends on the project
+	to which you're committing.  For example, it may certify that
+	the committer has the rights to submit the work under the
+	project's license or agrees to some contributor representation,
+	such as a Developer Certificate of Origin.
+	(See http://developercertificate.org for the one used by the
+	Linux kernel and Git projects.)  Consult the documentation or
+	leadership of the project to which you're contributing to
+	understand how the signoffs are used in that project.
 +
 The --no-signoff option can be used to countermand an earlier --signoff
 option on the command line.
-- 
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter

[PATCH v3 3/4] SubmittingPatches: clarify DCO is our --signoff rule

[Bradley M. Kuhn]

From: Junio C Hamano <gitster@pobox.com>

The description on sign-off and DCO was written back in the days
where there was only a choice between "use sign-off and it means the
contributor agrees to the Linux-kernel style DCO" and "not using
sign-off at all will make your patch unusable".  These days, we are
trying to clarify that the exact meaning of a sign-off varies
project to project.

Let's be more explicit when presenting what _our_ rules are.  It is
of secondary importance that it originally came from the kernel
project, so move the description as a historical note at the end,
while cautioning that what a sign-off means to us may be different from
what it means to other projects contributors may have been used to.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reviewed-by: Taylor Blau <me@ttaylorr.com>
Reviewed-by: Bradley M. Kuhn <bkuhn@sfconservancy.org>
---
 Documentation/SubmittingPatches | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 291b61e262..f83a050b35 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -300,15 +300,12 @@ patch.
 [[sign-off]]
 === Certify your work by adding your "Signed-off-by: " line
 
-To improve tracking of who did what, we've borrowed the
-"sign-off" procedure from the Linux kernel project on patches
-that are being emailed around.  Although core Git is a lot
-smaller project it is a good discipline to follow it.
+To improve tracking of who did what, we ask you to certify that you
+wrote the patch or have the right to pass it on under the same license
+as ours, by "signing off" your patch.  Without sign-off, we cannot
+accept your patches.
 
-The sign-off is a simple line at the end of the explanation for
-the patch, which certifies that you wrote it or otherwise have
-the right to pass it on as an open-source patch.  The rules are
-pretty simple: if you can certify the below D-C-O:
+If you can certify the below D-C-O:
 
 [[dco]]
 .Developer's Certificate of Origin 1.1
@@ -338,14 +335,15 @@ d. I understand and agree that this project and the contribution
    this project or the open source license(s) involved.
 ____
 
-then you just add a line saying
+you add a "Signed-off-by" trailer to your commit, that looks like
+this:
 
 ....
 	Signed-off-by: Random J Developer <random@developer.example.org>
 ....
 
-This line can be automatically added by Git if you run the git-commit
-command with the -s option.
+This line can be added by Git if you run the git-commit command with
+the -s option.
 
 Notice that you can place your own Signed-off-by: line when
 forwarding somebody else's patch with the above rules for
@@ -353,6 +351,11 @@ D-C-O.  Indeed you are encouraged to do so.  Do not forget to
 place an in-body "From: " line at the beginning to properly attribute
 the change to its true author (see (2) above).
 
+This procedure originally came from the Linux kernel project, so our
+rule is quite similar to theirs, but what exactly it means to sign-off
+your patch differs from project to project, so it may be different
+from that of the project you are accustomed to.
+
 [[real-name]]
 Also notice that a real name is used in the Signed-off-by: line. Please
 don't hide your real name.
-- 
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter

[PATCH v3 4/4] Documentation: stylistically normalize references to Signed-off-by:

[Bradley M. Kuhn]

Ted reported an old typo in the git-commit.txt and merge-options.txt.
Namely, the phrase "Signed-off-by line" was used without either a
definite nor indefinite article.

Upon examination, it seems that the documentation (including items in
Documentation/, but also option help strings) have been quite
inconsistent on usage when referring to `Signed-off-by`.

First, very few places used a definite or indefinite article with the
phrase "Signed-off-by line", but that was the initial typo that led
to this investigation.  So, normalize using either an indefinite or
definite article consistently.

The original phrasing, in Commit 3f971fc425b (Documentation updates,
2005-08-14), is "Add Signed-off-by line".  Commit 6f855371a53 (Add
--signoff, --check, and long option-names. 2005-12-09) switched to
using "Add `Signed-off-by:` line", but didn't normalize the former
commit to match.  Later commits seem to have cut and pasted from one
or the other, which is likely how the usage became so inconsistent.

Junio stated on the git mailing list in
<xmqqy2k1dfoh.fsf@gitster.c.googlers.com> a preference to leave off
the colon.  Thus, prefer `Signed-off-by` (with backticks) for the
documentation files and Signed-off-by (without backticks) for option
help strings.

Additionally, Junio argued that "trailer" is now the standard term to
refer to `Signed-off-by`, saying that "becomes plenty clear that we
are not talking about any random line in the log message".  As such,
prefer "trailer" over "line" anywhere the former word fits.

However, leave alone those few places in documentation that use
Signed-off-by to refer to the process (rather than the specific
trailer), or in places where mail headers are generally discussed in
comparison with Signed-off-by.

Reported-by: "Theodore Y. Ts'o" <tytso@mit.edu>
Signed-off-by: Bradley M. Kuhn <bkuhn@sfconservancy.org>
Acked-by: Taylor Blau <me@ttaylorr.com>
---
 Documentation/MyFirstContribution.txt |  2 +-
 Documentation/SubmittingPatches       | 10 +++++-----
 Documentation/config/format.txt       |  2 +-
 Documentation/git-am.txt              |  2 +-
 Documentation/git-cherry-pick.txt     |  2 +-
 Documentation/git-format-patch.txt    |  2 +-
 Documentation/git-rebase.txt          |  2 +-
 Documentation/git-revert.txt          |  2 +-
 Documentation/git-send-email.txt      |  4 ++--
 Documentation/git-svn.txt             |  4 ++--
 Documentation/githooks.txt            |  2 +-
 Documentation/signoff-option.txt      |  2 +-
 builtin/am.c                          |  2 +-
 builtin/commit.c                      |  2 +-
 builtin/log.c                         |  2 +-
 builtin/merge.c                       |  2 +-
 builtin/pull.c                        |  2 +-
 builtin/rebase.c                      |  2 +-
 builtin/revert.c                      |  2 +-
 commit.c                              |  2 +-
 20 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt
index 4f85a089ef..492f3998f7 100644
--- a/Documentation/MyFirstContribution.txt
+++ b/Documentation/MyFirstContribution.txt
@@ -249,7 +249,7 @@ component you're working on, followed by a blank line (always required) and then
 the body of your commit message, which should provide the bulk of the context.
 Remember to be explicit and provide the "Why" of your change, especially if it
 couldn't easily be understood from your diff. When editing your commit message,
-don't remove the Signed-off-by line which was added by `-s` above.
+don't remove the `Signed-off-by` trailer which was added by `-s` above.
 
 ----
 psuh: add a built-in by popular demand
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index f83a050b35..3bf2147787 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -209,7 +209,7 @@ send them as replies to either an additional "cover letter" message
 (see below), the first patch, or the respective preceding patch.
 
 If your log message (including your name on the
-Signed-off-by line) is not writable in ASCII, make sure that
+`Signed-off-by` trailer) is not writable in ASCII, make sure that
 you send off a message in the correct encoding.
 
 WARNING: Be wary of your MUAs word-wrap
@@ -229,7 +229,7 @@ previously sent.
 The `git format-patch` command follows the best current practice to
 format the body of an e-mail message.  At the beginning of the
 patch should come your commit message, ending with the
-Signed-off-by: lines, and a line that consists of three dashes,
+`Signed-off-by` trailers, and a line that consists of three dashes,
 followed by the diffstat information and the patch itself.  If
 you are forwarding a patch from somebody else, optionally, at
 the beginning of the e-mail message just before the commit
@@ -298,7 +298,7 @@ Do not forget to add trailers such as `Acked-by:`, `Reviewed-by:` and
 patch.
 
 [[sign-off]]
-=== Certify your work by adding your "Signed-off-by: " line
+=== Certify your work by adding your `Signed-off-by` trailer
 
 To improve tracking of who did what, we ask you to certify that you
 wrote the patch or have the right to pass it on under the same license
@@ -345,7 +345,7 @@ this:
 This line can be added by Git if you run the git-commit command with
 the -s option.
 
-Notice that you can place your own Signed-off-by: line when
+Notice that you can place your own `Signed-off-by` trailer when
 forwarding somebody else's patch with the above rules for
 D-C-O.  Indeed you are encouraged to do so.  Do not forget to
 place an in-body "From: " line at the beginning to properly attribute
@@ -357,7 +357,7 @@ your patch differs from project to project, so it may be different
 from that of the project you are accustomed to.
 
 [[real-name]]
-Also notice that a real name is used in the Signed-off-by: line. Please
+Also notice that a real name is used in the `Signed-off-by` trailer. Please
 don't hide your real name.
 
 [[commit-trailers]]
diff --git a/Documentation/config/format.txt b/Documentation/config/format.txt
index c2efd8758a..851bf410a3 100644
--- a/Documentation/config/format.txt
+++ b/Documentation/config/format.txt
@@ -79,7 +79,7 @@ format.thread::
 
 format.signOff::
 	A boolean value which lets you enable the `-s/--signoff` option of
-	format-patch by default. *Note:* Adding the Signed-off-by: line to a
+	format-patch by default. *Note:* Adding the `Signed-off-by` trailer to a
 	patch should be a conscious act and means that you certify you have
 	the rights to submit this work under the same open source license.
 	Please see the 'SubmittingPatches' document for further discussion.
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 38c0852139..06bc063542 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -33,7 +33,7 @@ OPTIONS
 
 -s::
 --signoff::
-	Add a `Signed-off-by:` line to the commit message, using
+	Add a `Signed-off-by` trailer to the commit message, using
 	the committer identity of yourself.
 	See the signoff option in linkgit:git-commit[1] for more information.
 
diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index 75feeef08a..5d750314b2 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -104,7 +104,7 @@ effect to your index in a row.
 
 -s::
 --signoff::
-	Add Signed-off-by line at the end of the commit message.
+	Add a `Signed-off-by` trailer at the end of the commit message.
 	See the signoff option in linkgit:git-commit[1] for more information.
 
 -S[<keyid>]::
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 0f81d0437b..bf1bb40f63 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -119,7 +119,7 @@ include::diff-options.txt[]
 
 -s::
 --signoff::
-	Add `Signed-off-by:` line to the commit message, using
+	Add a `Signed-off-by` trailer to the commit message, using
 	the committer identity of yourself.
 	See the signoff option in linkgit:git-commit[1] for more information.
 
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 38e15488f6..a0487b5cc5 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -496,7 +496,7 @@ See also INCOMPATIBLE OPTIONS below.
 See also INCOMPATIBLE OPTIONS below.
 
 --signoff::
-	Add a Signed-off-by: trailer to all the rebased commits. Note
+	Add a `Signed-off-by` trailer to all the rebased commits. Note
 	that if `--interactive` is given then only commits marked to be
 	picked, edited or reworded will have the trailer added.
 +
diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
index 044276e9da..bb92a4a451 100644
--- a/Documentation/git-revert.txt
+++ b/Documentation/git-revert.txt
@@ -99,7 +99,7 @@ effect to your index in a row.
 
 -s::
 --signoff::
-	Add Signed-off-by line at the end of the commit message.
+	Add a `Signed-off-by` trailer at the end of the commit message.
 	See the signoff option in linkgit:git-commit[1] for more information.
 
 --strategy=<strategy>::
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 0a69810147..b7bbbeadef 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -313,7 +313,7 @@ Automating
 	the value of `sendemail.identity`.
 
 --[no-]signed-off-by-cc::
-	If this is set, add emails found in Signed-off-by: or Cc: lines to the
+	If this is set, add emails found in the `Signed-off-by` trailer or Cc: lines to the
 	cc list. Default is the value of `sendemail.signedoffbycc` configuration
 	value; if that is unspecified, default to --signed-off-by-cc.
 
@@ -340,7 +340,7 @@ Automating
   except for self (use 'self' for that).
 - 'bodycc' will avoid including anyone mentioned in Cc lines in the
   patch body (commit message) except for self (use 'self' for that).
-- 'sob' will avoid including anyone mentioned in Signed-off-by lines except
+- 'sob' will avoid including anyone mentioned in the Signed-off-by trailers except
   for self (use 'self' for that).
 - 'misc-by' will avoid including anyone mentioned in Acked-by,
   Reviewed-by, Tested-by and other "-by" lines in the patch body,
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 6624a14fbd..67b143cc81 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -701,7 +701,7 @@ creating the branch or tag.
 
 --use-log-author::
 	When retrieving svn commits into Git (as part of 'fetch', 'rebase', or
-	'dcommit' operations), look for the first `From:` or `Signed-off-by:` line
+	'dcommit' operations), look for the first `From:` line or `Signed-off-by` trailer
 	in the log message and use that as the author string.
 +
 [verse]
@@ -710,7 +710,7 @@ config key: svn.useLogAuthor
 --add-author-from::
 	When committing to svn from Git (as part of 'set-tree' or 'dcommit'
 	operations), if the existing log message doesn't already have a
-	`From:` or `Signed-off-by:` line, append a `From:` line based on the
+	`From:` or `Signed-off-by` trailer, append a `From:` line based on the
 	Git commit's author string.  If you use this, then `--use-log-author`
 	will retrieve a valid author string for all commits.
 +
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 6e461ace6e..4e097dc4e9 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -164,7 +164,7 @@ can also be used to refuse the commit after inspecting the message
 file.
 
 The default 'commit-msg' hook, when enabled, detects duplicate
-"Signed-off-by" lines, and aborts the commit if one is found.
+`Signed-off-by` trailers, and aborts the commit if one is found.
 
 post-commit
 ~~~~~~~~~~~
diff --git a/Documentation/signoff-option.txt b/Documentation/signoff-option.txt
index fbff8dd5be..12aa2333e4 100644
--- a/Documentation/signoff-option.txt
+++ b/Documentation/signoff-option.txt
@@ -3,7 +3,7 @@ ifdef::git-commit[]
 endif::git-commit[]
 --signoff::
 --no-signoff::
-	Add a Signed-off-by trailer by the committer at the end of the commit
+	Add a `Signed-off-by` trailer by the committer at the end of the commit
 	log message.  The meaning of a signoff depends on the project
 	to which you're committing.  For example, it may certify that
 	the committer has the rights to submit the work under the
diff --git a/builtin/am.c b/builtin/am.c
index 2c7673f74e..26f53cdc09 100644
--- a/builtin/am.c
+++ b/builtin/am.c
@@ -2237,7 +2237,7 @@ int cmd_am(int argc, const char **argv, const char *prefix)
 			N_("allow fall back on 3way merging if needed")),
 		OPT__QUIET(&state.quiet, N_("be quiet")),
 		OPT_SET_INT('s', "signoff", &state.signoff,
-			N_("add a Signed-off-by line to the commit message"),
+			N_("add a Signed-off-by trailer to the commit message"),
 			SIGNOFF_EXPLICIT),
 		OPT_BOOL('u', "utf8", &state.utf8,
 			N_("recode into utf8 (default)")),
diff --git a/builtin/commit.c b/builtin/commit.c
index 1dfd799ec5..505fe60956 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1507,7 +1507,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
 		OPT_STRING(0, "fixup", &fixup_message, N_("commit"), N_("use autosquash formatted message to fixup specified commit")),
 		OPT_STRING(0, "squash", &squash_message, N_("commit"), N_("use autosquash formatted message to squash specified commit")),
 		OPT_BOOL(0, "reset-author", &renew_authorship, N_("the commit is authored by me now (used with -C/-c/--amend)")),
-		OPT_BOOL('s', "signoff", &signoff, N_("add Signed-off-by:")),
+		OPT_BOOL('s', "signoff", &signoff, N_("add a Signed-off-by trailer")),
 		OPT_FILENAME('t', "template", &template_file, N_("use specified template file")),
 		OPT_BOOL('e', "edit", &edit_flag, N_("force edit of commit")),
 		OPT_CLEANUP(&cleanup_arg),
diff --git a/builtin/log.c b/builtin/log.c
index 0a7ed4bef9..9f939e6cdf 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1738,7 +1738,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
 		OPT_CALLBACK_F('N', "no-numbered", &numbered, NULL,
 			    N_("use [PATCH] even with multiple patches"),
 			    PARSE_OPT_NOARG | PARSE_OPT_NONEG, no_numbered_callback),
-		OPT_BOOL('s', "signoff", &do_signoff, N_("add Signed-off-by:")),
+		OPT_BOOL('s', "signoff", &do_signoff, N_("add a Signed-off-by trailer")),
 		OPT_BOOL(0, "stdout", &use_stdout,
 			    N_("print patches to standard out")),
 		OPT_BOOL(0, "cover-letter", &cover_letter,
diff --git a/builtin/merge.c b/builtin/merge.c
index 9d5359edc2..4c133402a6 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -289,7 +289,7 @@ static struct option builtin_merge_options[] = {
 	  N_("GPG sign commit"), PARSE_OPT_OPTARG, NULL, (intptr_t) "" },
 	OPT_AUTOSTASH(&autostash),
 	OPT_BOOL(0, "overwrite-ignore", &overwrite_ignore, N_("update ignored files (default)")),
-	OPT_BOOL(0, "signoff", &signoff, N_("add Signed-off-by:")),
+	OPT_BOOL(0, "signoff", &signoff, N_("add a Signed-off-by trailer")),
 	OPT_BOOL(0, "no-verify", &no_verify, N_("bypass pre-merge-commit and commit-msg hooks")),
 	OPT_END()
 };
diff --git a/builtin/pull.c b/builtin/pull.c
index 425950f469..17aa63cd35 100644
--- a/builtin/pull.c
+++ b/builtin/pull.c
@@ -142,7 +142,7 @@ static struct option pull_options[] = {
 		N_("add (at most <n>) entries from shortlog to merge commit message"),
 		PARSE_OPT_OPTARG),
 	OPT_PASSTHRU(0, "signoff", &opt_signoff, NULL,
-		N_("add Signed-off-by:"),
+		N_("add a Signed-off-by trailer"),
 		PARSE_OPT_OPTARG),
 	OPT_PASSTHRU(0, "squash", &opt_squash, NULL,
 		N_("create a single commit instead of doing a merge"),
diff --git a/builtin/rebase.c b/builtin/rebase.c
index eeca53382f..7b65525301 100644
--- a/builtin/rebase.c
+++ b/builtin/rebase.c
@@ -1324,7 +1324,7 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)
 			N_("do not show diffstat of what changed upstream"),
 			PARSE_OPT_NOARG, NULL, REBASE_DIFFSTAT },
 		OPT_BOOL(0, "signoff", &options.signoff,
-			 N_("add a Signed-off-by: line to each commit")),
+			 N_("add a Signed-off-by trailer to each commit")),
 		OPT_BOOL(0, "committer-date-is-author-date",
 			 &options.committer_date_is_author_date,
 			 N_("make committer date match author date")),
diff --git a/builtin/revert.c b/builtin/revert.c
index f61cc5d82c..da8997dc86 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -107,7 +107,7 @@ static int run_sequencer(int argc, const char **argv, struct replay_opts *opts)
 		OPT_BOOL('n', "no-commit", &opts->no_commit, N_("don't automatically commit")),
 		OPT_BOOL('e', "edit", &opts->edit, N_("edit the commit message")),
 		OPT_NOOP_NOARG('r', NULL),
-		OPT_BOOL('s', "signoff", &opts->signoff, N_("add Signed-off-by:")),
+		OPT_BOOL('s', "signoff", &opts->signoff, N_("add a Signed-off-by trailer")),
 		OPT_CALLBACK('m', "mainline", opts, N_("parent-number"),
 			     N_("select mainline parent"), option_parse_m),
 		OPT_RERERE_AUTOUPDATE(&opts->allow_rerere_auto),
diff --git a/commit.c b/commit.c
index f53429c0ac..fe1fa3dc41 100644
--- a/commit.c
+++ b/commit.c
@@ -1586,7 +1586,7 @@ const char *find_commit_header(const char *msg, const char *key, size_t *out_len
 
 /*
  * Inspect the given string and determine the true "end" of the log message, in
- * order to find where to put a new Signed-off-by: line.  Ignored are
+ * order to find where to put a new Signed-off-by trailer.  Ignored are
  * trailing comment lines and blank lines.  To support "git commit -s
  * --amend" on an existing commit, we also ignore "Conflicts:".  To
  * support "git commit -v", we truncate at cut lines.
-- 
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter

Re: [PATCH v2 2/3] Documentation: stylistically normalize references to Signed-off-by:

[Taylor Blau]

On Mon, Oct 19, 2020 at 03:17:02PM -0700, Junio C Hamano wrote:
> Taylor Blau <me@ttaylorr.com> writes:
>
> > I think that the 3-patch series that Junio was talking about in [1] is
> > actually this one [2].
> > ...
> > [1]: https://lore.kernel.org/git/xmqqmu0it6ls.fsf@gitster.c.googlers.com/
> > [2]: https://lore.kernel.org/git/20201018194912.2716372-1-gitster@pobox.com/
>
> True.
>
> I actually think it is a bad idea to add ":" after every mention of
> "Signed-off-by"; it only looks clarifying because we use a boring
> and generic word "line" to refer to where that three-word token
> appears.
>
> We can say "a 'Signed-off-by' trailer" and it becomes plenty clear
> that we are not talking about any random line in the log message,
> and we do not need ":" everywhere, I suspect.

Mm. I may be in the minority that I think having ":" after
"Signed-off-by" is helpful, but I'm happy to go whichever way others
find most clear.

> Thanks.

Thanks,
Taylor

Re: [PATCH v3 0/4] clarify meaning of --signoff & related doc improvements in describing Signed-off-by

[Taylor Blau]

Hi Bradley,

On Mon, Oct 19, 2020 at 06:03:51PM -0700, Bradley M. Kuhn wrote:
> [ Note that there were competing v2's of this patch series, one from me and
>   one from Junio.  Sorry about that; I had missed Junio's from Sunday. ]
>
> I believe this patch series now addresses all the issues raised in the
> discussion.
>
>   * [1/4] is unchanged from Junio's v2 and is the preparatory cleanup.
>
>   * [2/4] remains unchanged textually since I originally posted it and Pfeff
>     signed off.
>
>   * [3/4] is unchanged from Junio's v2 and is his clarification for what
>      Git's --signoff means.
>
>   * [4/4] is a rework of a patch from *my* v2.  It takes into account Junio's
>     comments about preferring the word "trailer" and leaving off the ':'
>     whenever possible when discussing Signed-off-by.

Thanks; I think some of our emails crossed over one another, but this
version looks good to me.

I'd be happy to discard what's currently in seen (integrated as
1b98087e0f (Merge branch 'bk/sob-dco' into jch, 2020-10-19 at the time
of writing) in favor of what's here.

Thanks,
Taylor

Re: [PATCH v3 4/4] Documentation: stylistically normalize references to Signed-off-by:

[Junio C Hamano]

"Bradley M. Kuhn" <bkuhn@sfconservancy.org> writes:

> Ted reported an old typo in the git-commit.txt and merge-options.txt.
> Namely, the phrase "Signed-off-by line" was used without either a
> definite nor indefinite article.
>
> Upon examination, it seems that the documentation (including items in
> Documentation/, but also option help strings) have been quite
> inconsistent on usage when referring to `Signed-off-by`.

Thanks.  This must have been a lot of proofreading ;-)

It seems the patches [1-3/4] are identical to what has been queued
in 'seen', which is a good sign.  There was a reversion of a typofix
in the log message of one of them, though.

> diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
> index 0a69810147..b7bbbeadef 100644
> --- a/Documentation/git-send-email.txt
> +++ b/Documentation/git-send-email.txt
> @@ -313,7 +313,7 @@ Automating
>  	the value of `sendemail.identity`.
>  
>  --[no-]signed-off-by-cc::
> -	If this is set, add emails found in Signed-off-by: or Cc: lines to the
> +	If this is set, add emails found in the `Signed-off-by` trailer or Cc: lines to the
>  	cc list. Default is the value of `sendemail.signedoffbycc` configuration
>  	value; if that is unspecified, default to --signed-off-by-cc.
>  
> @@ -340,7 +340,7 @@ Automating
>    except for self (use 'self' for that).
>  - 'bodycc' will avoid including anyone mentioned in Cc lines in the
>    patch body (commit message) except for self (use 'self' for that).
> -- 'sob' will avoid including anyone mentioned in Signed-off-by lines except
>
> +- 'sob' will avoid including anyone mentioned in the Signed-off-by trailers except
>    for self (use 'self' for that).
>  - 'misc-by' will avoid including anyone mentioned in Acked-by,
>    Reviewed-by, Tested-by and other "-by" lines in the patch body,
>
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt

Did you hand edit the second hunk starting at line 340 to
git-send-email.txt?  I've fixed it up manually, so no need to
resend.

Thanks.

Re: [PATCH v3 0/4] clarify meaning of --signoff & related doc improvements in describing Signed-off-by

[Bradley M. Kuhn]

Taylor Blau wrote:
> Thanks; I think some of our emails crossed over one another, but this
> version looks good to me.

Yes, I was preparing the patch when you wrote that you disagreed with Junio
and preferred the ":".

FWIW, I left the ":" anywhere headers were being discussed and those headers
were described with ":"s on them.  I only changed places where
"Signed-off-by:" stood alone.

Before my v3 patchset, usage was inconsistent about (roughly half/half), so
the decision is mostly a coin toss.  I didn't have a strong opinion when I
was first writing the v3 patchset, but having thought about it overnight, I
now think leaving the ":" *out* is better because a reader new to Git is more
likely to think a ":" is punctuation, rather than being part of a moniker.
Thus, IMO, leaving out the ":" in most cases probably improves readability.


The remainder of this email is purely an edification question that may help
serve to improve Documentation/SubmittingPatches:

> I'd be happy to discard what's currently in seen (integrated as 1b98087e0f
> (Merge branch 'bk/sob-dco' into jch, 2020-10-19 at the time of writing) in
> favor of what's here.

I wasn't sure what I should be doing with the patch set once it was already
in 'seen'.  The only two references in SubmittingPatches I could find were:

From Documentation/SubmittingPatches:
>> In any time between the (2)-(3) cycle, the maintainer may pick it up from
>> the list and queue it to `seen`, in order to make it easier for people
>> play with it without having to pick up and apply the patch to their trees
>> themselves.

and

>> `git pull --rebase` will automatically skip already-applied patches, and
>> will let you know. This works only if you rebase on top of the branch in
>> which your patch has been merged (i.e. it will not tell you if your patch
>> is merged in `seen` if you rebase on top of master).

The former hints that you *shouldn't* change the workflow if some of your
patchset is in `seen`, and the latter hints that maybe you should, but
neither section tells you what to do differently, if anything, once your
patches are in `seen`.

I'm curious to know if I went wrong somewhere and the workflow and would be
glad to propose another patch to improve SubmittingPatches with a section of
what to do when patches show up in `seen`, but since I'm a n00b (at least as
an upstream Git contributor :), I'd need to know how to DTRT in this case to
do that.
--
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter

Re: [PATCH v3 4/4] Documentation: stylistically normalize references to Signed-off-by:

[Bradley M. Kuhn]

Junio C Hamano wrote:
> Did you hand edit the second hunk starting at line 340 to
> git-send-email.txt?

I don't think so, although this is only the third time I've used the git
format-patch/send-email workflow so it's entirely possible I did something
funky …

>  I've fixed it up manually, so no need to resend.

… but thanks for taking care of it!

--
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter

Re: [PATCH v3 2/4] Documentation: clarify and expand description of --signoff

[Bradley M. Kuhn]

Junio,

Junio wrote in the sub-thread about [PATCH v3 4/4]:
>> It seems the patches [1-3/4] are identical to what has been queued
>> in 'seen', which is a good sign.

One change I made in v3 patchset was to add Peff's Signed-off-by, as it
is *not* there in commit 04c2b9ebd0 in seen:

I wrote in [PATCH v3 2/4]:
> Signed-off-by: Jeff King <peff@peff.net>

… given that Peff made edits to this before it was posted, I think we want to
be sure Peff's Signed-off-by is included.  It just seems like the "right
thing" to get the Signed-off-by trailers 100% correct on a commit that
changes the description of Signed-off-by. 😆

I wrote in [PATCH v3 2/4]:
> Reviewed-by: Taylor Blau <me@ttaylorr.com>

I doubt Taylor cares whether this Reviewed-by trailer makes it in,
but I did add that too based on Taylor providing it earlier in the
discussion of this patch. ☺
--
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter

Re: [PATCH v3 0/4] clarify meaning of --signoff & related doc improvements in describing Signed-off-by

[Taylor Blau]

Hi Bradley,

On Tue, Oct 20, 2020 at 02:28:20PM -0700, Bradley M. Kuhn wrote:
> The remainder of this email is purely an edification question that may help
> serve to improve Documentation/SubmittingPatches:
>
> > I'd be happy to discard what's currently in seen (integrated as 1b98087e0f
> > (Merge branch 'bk/sob-dco' into jch, 2020-10-19 at the time of writing) in
> > favor of what's here.
>
> I wasn't sure what I should be doing with the patch set once it was already
> in 'seen'.  The only two references in SubmittingPatches I could find were:

The conclusive answer is that you can do anything you want when the
patches are in 'seen', but when it is in 'next', things have solidified
and the series is not meant to be changed. The one exception to that
rule is immediately after a release, in which case 'next' is rewound
(and thus some topics can be ejected from next).

> From Documentation/SubmittingPatches:
> >> In any time between the (2)-(3) cycle, the maintainer may pick it up from
> >> the list and queue it to `seen`, in order to make it easier for people
> >> play with it without having to pick up and apply the patch to their trees
> >> themselves.
>
> and
>
> >> `git pull --rebase` will automatically skip already-applied patches, and
> >> will let you know. This works only if you rebase on top of the branch in
> >> which your patch has been merged (i.e. it will not tell you if your patch
> >> is merged in `seen` if you rebase on top of master).
>
> The former hints that you *shouldn't* change the workflow if some of your
> patchset is in `seen`, and the latter hints that maybe you should, but
> neither section tells you what to do differently, if anything, once your
> patches are in `seen`.

I think the latter is really only talking about branches based on
'master' (of course, the same thing is true of branches based on any
branch, but it's uncommon to base topics off of 'seen').

The former is saying that 'seen' may change zero, one, or multiple times
during the lifetime of a topic. The latter says if you track upstream's
'master' and then 'git pull --rebase', 'git rebase' will tell you if
your patches are already applied upstream (in which case you can drop
them).

> I'm curious to know if I went wrong somewhere and the workflow and would be
> glad to propose another patch to improve SubmittingPatches with a section of
> what to do when patches show up in `seen`, but since I'm a n00b (at least as
> an upstream Git contributor :), I'd need to know how to DTRT in this case to
> do that.

It couldn't hurt to add something to the effect of:

  Since 'seen' is a convenience branch that contains the current state
  of the in-flight topics, it is subject to be changed and rebuilt
  multiple times (c.f., link:howto/maintain-git) so the presence of your
  patches in 'seen' (but not 'next' or 'master') should not affect your
  workflow.

Thanks,
Taylor

Re: [PATCH v3 2/4] Documentation: clarify and expand description of --signoff

[Taylor Blau]

On Tue, Oct 20, 2020 at 02:44:31PM -0700, Bradley M. Kuhn wrote:
> > Reviewed-by: Taylor Blau <me@ttaylorr.com>
>
> I doubt Taylor cares whether this Reviewed-by trailer makes it in,
> but I did add that too based on Taylor providing it earlier in the
> discussion of this patch. ☺

He doesn't ;-).

Thanks,
Taylor

Re: [PATCH v3 0/4] clarify meaning of --signoff & related doc improvements in describing Signed-off-by

[Junio C Hamano]

"Bradley M. Kuhn" <bkuhn@sfconservancy.org> writes:

> I wasn't sure what I should be doing with the patch set once it was already
> in 'seen'.  The only two references in SubmittingPatches I could find were:

Being 'seen' is an indication that it has been seen and does not
mean anything more than that.  It is appreciated that a topic in
such a state is improved by replacing.

> From Documentation/SubmittingPatches:
>>> In any time between the (2)-(3) cycle, the maintainer may pick it up from
>>> the list and queue it to `seen`, in order to make it easier for people
>>> play with it without having to pick up and apply the patch to their trees
>>> themselves.

Yes.  Other people then can "git fetch" from me and follow the first
parent chain "git log --first-parent origin/master..origin/seen" to
find the tip of your topic, instead of finding your message in the
list archive and running "git am" themselves.

The original submitter/owner of the topic can also find the tip of
the topic _in_ my tree the same way as others and reset their branch
to what is queued in 'seen' if they wanted to keep minor fixes I
made based on review comments while applying the e-mailed patches.

Then they can further work on polishing the topic with the usual
means, e.g. using "rebase -i", and finally "format-patch" to send
out a new round.  Being or not being in 'seen' does not change the
workflow that much.

>>> `git pull --rebase` will automatically skip already-applied patches, and
>>> will let you know. This works only if you rebase on top of the branch in
>>> which your patch has been merged (i.e. it will not tell you if your patch
>>> is merged in `seen` if you rebase on top of master).

This is talking about a fairly mature topic that has already been in
'next' and was on the course to graduate to 'master'.  The topic
would eventually be in 'master', and at that point "pull --rebase"
would notice that the patches are no longer needed (or were merged
in a different form).  But that does not apply to topics that are
not in 'master' yet.

Where the workflow changes is when the topic hits 'next'.  After
that, we request you to give incremental updates to refine what is
queued already.  

The reasoning behind this is simple and arbitrary.  It often is the
case that keeping mistakes in early iterations, and fixes to these
mistakes, recorded in history is not worth the attention of future
readers of "git log" who need to study the history, assuming that
trivial mistakes are caught early.  Once earlier rounds of review is
done and everybody is more or less happy, the topic gets merged to
'next', and after that point, a new issue that gets noticed and
fixed _are_ worth recording in history, because both the original
contributor and reviewers failed to catch such glitches.

> I'm curious to know if I went wrong somewhere and the workflow and would be
> glad to propose another patch to improve SubmittingPatches with a section of
> what to do when patches show up in `seen`, but since I'm a n00b (at least as
> an upstream Git contributor :), I'd need to know how to DTRT in this case to
> do that.

I thought your v3 did things perfectly.

Thanks.

Re: [PATCH v3 0/4] clarify meaning of --signoff & related doc improvements in describing Signed-off-by

[Bradley M. Kuhn]

> "Bradley M. Kuhn" <bkuhn@sfconservancy.org> writes:
> > I wasn't sure what I should be doing with the patch set once it was already
> > in 'seen'.

Junio C Hamano wrote:
> Being 'seen' is an indication that it has been seen and does not mean
> anything more than that.

Documentation/SubmittingPatches says:
> >>> `git pull --rebase` will automatically skip already-applied patches, and
> >>> will let you know. This works only if you rebase on top of the branch in
> >>> which your patch has been merged (i.e. it will not tell you if your patch
> >>> is merged in `seen` if you rebase on top of master).

> This is talking about a fairly mature topic that has already been in 'next'
> and was on the course to graduate to 'master'.  The topic would eventually
> be in 'master', and at that point "pull --rebase" would notice that the
> patches are no longer needed (or were merged in a different form).  But
> that does not apply to topics that are not in 'master' yet.

Junio, thanks for your detailed reply.  I have a couple ideas of some
minor changes to SubmittingPatches that would have made what you said clearer
to me when I was doing my first patch.  I'll think about it some and send
something along, but probably won't get to it until next month (but it
doesn't seem urgent).

Taylor wrote: 

>>> Since 'seen' is a convenience branch that contains the current state
>>>  of the in-flight topics, it is subject to be changed and rebuilt
>>>  multiple times (c.f., link:howto/maintain-git) so the presence of your
>>>  patches in 'seen' (but not 'next' or 'master') should not affect your
>>>  workflow.

I'll hold on to this text as a possibility, to start from when I dig
into the proposals above.  Thanks!
--
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter