git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH RFC] git-am: support any number of signatures
Date: Sun, 15 Jun 2014 13:27:36 +0300	[thread overview]
Message-ID: <20140615102736.GA11798@redhat.com> (raw)
In-Reply-To: <xmqqy4x03ecm.fsf@gitster.dls.corp.google.com>

On Fri, Jun 13, 2014 at 10:32:09AM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> > On Thu, Jun 12, 2014 at 12:07:03PM -0700, Junio C Hamano wrote:
> >> "Michael S. Tsirkin" <mst@redhat.com> writes:
> >> ...
> >> > 1.  new parameter am.signoff can be used any number
> >> > 	of times:
> >> >
> >> > [am]
> >> > 	signoff = "Reviewed-by: Michael S. Tsirkin <mst@redhat.com>"
> >> > 	signoff = "Signed-off-by: Michael S. Tsirkin <mst@redhat.com>"
> >> >
> >> > 	if set all signatures are picked up when git am -s is used.
> >> 
> >> How does this interact with the logic to avoid appending the same
> >> Signed-off-by: line as the last one the incoming message already
> >> has?
> >
> > Not handled if you have multiple signatures.
> > That will have to be fixed.
> > Do we only care about the last line?
> >
> > Signed-off-by: A
> > Signed-off-by: B
> >
> > do we want to add
> >
> > Signed-off-by: A
> >
> > or would it be better to replace with
> > Signed-off-by: B
> > Signed-off-by: A
> >
> > ?
> >
> > Current git am will add A twice, I wonder if this is
> > a feature or a bug.
> 
> This is very much deliberate.
> 
> Appending A after existing A and B is meant to record that the patch
> originated from A, passed thru B possibly with changes by B, came
> back to A who wants to assert that the result is still under DCO.
> 
> The only case we can safely omit appending A's sign-off is when the
> last one in the chain is by A.  Imagine that you had a patch signed
> off by B, which A may have tweaked and forwarded under DCO with A's
> sign-off.  Such a patch would have sign-off chain B-A.
> 
> Now A makes further changes to the patch and says "the further
> change is also something I am authorized to release as open source"
> with the "-s" option or some other way.  It would not change that A
> can contribute under DCO if we did not add an extra A after existing
> B-A sign-off chain in that case.

OK imagine we have signatures:
A
B

Now A wants to sign this patch.

I think there are two reasonable ways to behave:
1. What you describe above:
A
B
A

2. For things like Tested-by: tags, removing tag from
where it was and adding it at the bottom:

B
A


This probably calls for a separate feature:
maybe adding "acks" along with "signoffs"?
acks would be unique, re-adding ack removes it from
the message and adds at the bottom.

-- 
MST

  reply	other threads:[~2014-06-15 10:30 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-12 16:12 [PATCH RFC] git-am: support any number of signatures Michael S. Tsirkin
2014-06-12 19:07 ` Junio C Hamano
2014-06-13  8:00   ` Michael S. Tsirkin
2014-06-13 17:32     ` Junio C Hamano
2014-06-15 10:27       ` Michael S. Tsirkin [this message]
2014-06-16 18:06         ` Junio C Hamano
2014-06-18  3:09           ` Michael S. Tsirkin
2014-06-18  6:49             ` Junio C Hamano
2014-06-18  7:33               ` Michael S. Tsirkin
2014-06-18 17:51               ` Junio C Hamano
2014-06-18 18:23                 ` Michael S. Tsirkin
2014-09-22 14:01                 ` Michael S. Tsirkin
2014-09-22 17:58                   ` Junio C Hamano
2014-09-23  7:45                   ` Christian Couder
2014-09-23  8:07                     ` Michael S. Tsirkin
2014-09-24 10:00                       ` Christian Couder
2014-10-07 21:33                         ` Michael S. Tsirkin
2014-09-23 17:15                     ` Junio C Hamano
2014-09-25  5:04                       ` Junio C Hamano
2014-09-25 10:04                       ` Christian Couder
2014-09-25 16:20                         ` Junio C Hamano
2014-09-28 11:36                           ` Christian Couder
     [not found]                             ` <7viok7k0c0.fsf@alter.siamese.dyndns.org>
2014-10-12  9:36                               ` Christian Couder
2014-10-13  5:09                                 ` Christian Couder
2014-10-13 22:05                                   ` Junio C Hamano
2014-10-14  5:29                                     ` Christian Couder
2014-10-07 21:29                       ` Michael S. Tsirkin
2014-10-07 21:39                         ` Jeff King
2014-10-07 21:41                           ` Junio C Hamano
2014-06-12 19:25 ` René Scharfe
2014-06-13  8:01   ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140615102736.GA11798@redhat.com \
    --to=mst@redhat.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).