git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH RFC] git-am: support any number of signatures

From
MTMichael S. Tsirkin <mst@redhat.com>
Date
Jun 15, 2014, 10:27 UTC
Message-ID
<20140615102736.GA11798@redhat.com>
In-Reply-To
<xmqqy4x03ecm.fsf@gitster.dls.corp.google.com>
On Fri, Jun 13, 2014 at 10:32:09AM -0700, Junio C Hamano wrote:
Show 54 quoted lines
> "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
Previous: Junio C HamanoNext: Junio C Hamano
Message 5 of 31 in “git-am: support any number of signatures”
  1. git-am: support any number of signaturesMichael S. Tsirkin, Jun 12, 2014
  2. Junio C HamanoJun 12, 2014
  3. Michael S. TsirkinJun 13, 2014
  4. Junio C HamanoJun 13, 2014
  5. Michael S. TsirkinJun 15, 2014
  6. Junio C HamanoJun 16, 2014
  7. Michael S. TsirkinJun 18, 2014
  8. Junio C HamanoJun 18, 2014
  9. Michael S. TsirkinJun 18, 2014
  10. Junio C HamanoJun 18, 2014
  11. Michael S. TsirkinJun 18, 2014
  12. Michael S. TsirkinSep 22, 2014
  13. Junio C HamanoSep 22, 2014
  14. Christian CouderSep 23, 2014
  15. Michael S. TsirkinSep 23, 2014
  16. Christian CouderSep 24, 2014
  17. Michael S. TsirkinOct 7, 2014
  18. Junio C HamanoSep 23, 2014
  19. Junio C HamanoSep 25, 2014
  20. Christian CouderSep 25, 2014
  21. Junio C HamanoSep 25, 2014
  22. Christian CouderSep 28, 2014
  23. Michael S. TsirkinOct 7, 2014
  24. Jeff KingOct 7, 2014
  25. Junio C HamanoOct 7, 2014
  26. René ScharfeJun 12, 2014
  27. Michael S. TsirkinJun 13, 2014
  28. Christian CouderOct 12, 2014
  29. Christian CouderOct 13, 2014
  30. Junio C HamanoOct 13, 2014
  31. Christian CouderOct 14, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.