git am and duplicate signatures

git am and duplicate signatures

[Joe Perches]

git-am -s will avoid duplicating the last signature
in a patch.

But given a developer creates a patch, send it around for
acks/other signoffs, collects signatures and then does
a git am -s on a different branch, this sort of sign-off
chain is possible:

	Signed-off-by: Original Developer <od@domain.com>
	Acked-by: Random Developer <rd@domain.com>
	Signed-off-by: Original Developer <od@domain.com>

Should there be an option to avoid duplicate signatures
in a sequence where an author can git-am the same patch?

sequencer.c:append_signoff() has a flag for APPEND_SIGNOFF_DEDUP

sequencer.c:void append_signoff(struct strbuf *msgbuf, int ignore_footer, unsigned flag)

but

builtin/commit.c:               append_signoff(&sb, ignore_non_trailer(&sb), 0);

doesn't have an optional use mechanism available.

Re: git am and duplicate signatures

[Junio C Hamano]

Joe Perches <joe@perches.com> writes:

> git-am -s will avoid duplicating the last signature
> in a patch.
>
> But given a developer creates a patch, send it around for
> acks/other signoffs, collects signatures and then does
> a git am -s on a different branch, this sort of sign-off
> chain is possible:
>
> 	Signed-off-by: Original Developer <od@domain.com>
> 	Acked-by: Random Developer <rd@domain.com>
> 	Signed-off-by: Original Developer <od@domain.com>

Both correct and allowing the earlier one duplicated as long as
there is somebody/something else in between is deliberate.

> Should there be an option to avoid duplicate signatures
> in a sequence where an author can git-am the same patch?

I dunno.  The way "Signed-off-by" is handled is designed
specifically to support the meaning of that footer, namely to record
where it originated and whose hands it passed, used in the kernel
and Git land.  Other projects certainly may have need for footers
that denote different things that want different semantics (e.g. Who
authored it and who cheered on it), but that is outside the scope of
the "Signed-off-by" supported by "am -s" and "commit -s".

Support for more generic footers was supposed to come when the
"interpret-trailers" topic started, but the author of the topic
seems to have lost interest before the mechanism has become ready to
be integrated in the workflow commands like "am", "commit", "rebase"
etc., which is unfortunate.

> sequencer.c:append_signoff() has a flag for APPEND_SIGNOFF_DEDUP

Yes, I think this is one of the warts we talked about getting rid of
but haven't got around to it.  It is there because "format-patch -s"
was incorrectly written to dedup Signed-off-by: from anywhere in its
early implementation and to keep the same behaviour.  We should drop
that flag from append_signoff() function.

Re: git am and duplicate signatures

[Joe Perches]

(adding lkml)

On Tue, 2016-08-30 at 09:54 -0700, Junio C Hamano wrote:
> Joe Perches <joe@perches.com> writes:
> > git-am -s will avoid duplicating the last signature
> > in a patch.
> > 
> > But given a developer creates a patch, send it around for
> > acks/other signoffs, collects signatures and then does
> > a git am -s on a different branch, this sort of sign-off
> > chain is possible:
> > 
> > 	Signed-off-by: Original Developer <od@domain.com>
> > 	Acked-by: Random Developer <rd@domain.com>
> > 	Signed-off-by: Original Developer <od@domain.com>
> Both correct and allowing the earlier one duplicated as long as
> there is somebody/something else in between is deliberate.

linux-kernel has a script (scripts/checkpatch.pl) that
looks for duplicate signatures (<foo>-by: [name] <address>)

Should the last Signed-off-by: in the commit log be
excluded from this check?

> > Should there be an option to avoid duplicate signatures
> > in a sequence where an author can git-am the same patch?
> I dunno.  The way "Signed-off-by" is handled is designed
> specifically to support the meaning of that footer, namely to record
> where it originated and whose hands it passed, used in the kernel
> and Git land.  Other projects certainly may have need for footers
> that denote different things that want different semantics (e.g. Who
> authored it and who cheered on it), but that is outside the scope of
> the "Signed-off-by" supported by "am -s" and "commit -s".
> 
> Support for more generic footers was supposed to come when the
> "interpret-trailers" topic started, but the author of the topic
> seems to have lost interest before the mechanism has become ready to
> be integrated in the workflow commands like "am", "commit", "rebase"
> etc., which is unfortunate.
> 
> > 
> > sequencer.c:append_signoff() has a flag for APPEND_SIGNOFF_DEDUP
> Yes, I think this is one of the warts we talked about getting rid of
> but haven't got around to it.  It is there because "format-patch -s"
> was incorrectly written to dedup Signed-off-by: from anywhere in its
> early implementation and to keep the same behaviour.  We should drop
> that flag from append_signoff() function.

Re: git am and duplicate signatures

[Junio C Hamano]

Joe Perches <joe@perches.com> writes:

> (adding lkml)
>
> On Tue, 2016-08-30 at 09:54 -0700, Junio C Hamano wrote:
>> Joe Perches <joe@perches.com> writes:
>> > git-am -s will avoid duplicating the last signature
>> > in a patch.
>> > 
>> > But given a developer creates a patch, send it around for
>> > acks/other signoffs, collects signatures and then does
>> > a git am -s on a different branch, this sort of sign-off
>> > chain is possible:
>> > 
>> > 	Signed-off-by: Original Developer <od@domain.com>
>> > 	Acked-by: Random Developer <rd@domain.com>
>> > 	Signed-off-by: Original Developer <od@domain.com>
>> Both correct and allowing the earlier one duplicated as long as
>> there is somebody/something else in between is deliberate.
>
> linux-kernel has a script (scripts/checkpatch.pl) that
> looks for duplicate signatures (<foo>-by: [name] <address>)
>
> Should the last Signed-off-by: in the commit log be
> excluded from this check?

That is left for the kernel folks to decide, but excluding only "the
last" does not make much sense to me.  If you look for only "two
consecutive same signatures" and barf, that would be in line with
what we have been shooting for to support the above "original then
random then back to original" example you gave us above.

Re: git am and duplicate signatures

[Joe Perches]

On Tue, 2016-08-30 at 09:54 -0700, Junio C Hamano wrote:
> Support for more generic footers was supposed to come when the
> "interpret-trailers" topic started, but the author of the topic
> seems to have lost interest before the mechanism has become ready to
> be integrated in the workflow commands like "am", "commit", "rebase"
> etc., which is unfortunate.

I think adding at least an option to git send-email
allowing auto-cc's for all
	"<foo>-by: [name] <address>"
lines in the commit log would be useful.

Today, only "Signed-off-by" and "CC" lines are
added to cc's.

I've always called these lines "<foo>-by:" lines
"signatures", but perhaps there's a better name.

Any preference?

from git send-email --help
       --suppress-cc=<category>
           Specify an additional category of recipients to suppress the
           auto-cc of:

           ·   author will avoid including the patch author

           ·   self will avoid including the sender

           ·   cc will avoid including anyone mentioned in Cc lines in the
               patch header 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 for self (use self for that).

           ·   cccmd will avoid running the --cc-cmd.

           ·   body is equivalent to sob + bodycc

           ·   all will suppress all auto cc values.
> > 
> > sequencer.c:append_signoff() has a flag for APPEND_SIGNOFF_DEDUP
> Yes, I think this is one of the warts we talked about getting rid of
> but haven't got around to it.  It is there because "format-patch -s"
> was incorrectly written to dedup Signed-off-by: from anywhere in its
> early implementation and to keep the same behaviour.  We should drop
> that flag from append_signoff() function.

Re: git am and duplicate signatures

[Junio C Hamano]

Joe Perches <joe@perches.com> writes:

> On Tue, 2016-08-30 at 09:54 -0700, Junio C Hamano wrote:
>> Support for more generic footers was supposed to come when the
>> "interpret-trailers" topic started, but the author of the topic
>> seems to have lost interest before the mechanism has become ready to
>> be integrated in the workflow commands like "am", "commit", "rebase"
>> etc., which is unfortunate.
>
> I think adding at least an option to git send-email
> allowing auto-cc's for all
> 	"<foo>-by: [name] <address>"
> lines in the commit log would be useful.
>
> Today, only "Signed-off-by" and "CC" lines are
> added to cc's.
>
> I've always called these lines "<foo>-by:" lines
> "signatures", but perhaps there's a better name.

I think we casually call them footers (as they are counter-part to
"headers"), or trailers.

Re: git am and duplicate signatures

[Joe Perches]

On Tue, 2016-08-30 at 10:34 -0700, Junio C Hamano wrote:
> Joe Perches <joe@perches.com> writes:
> > On Tue, 2016-08-30 at 09:54 -0700, Junio C Hamano wrote:
> > > 
> > > Support for more generic footers was supposed to come when the
> > > "interpret-trailers" topic started, but the author of the topic
> > > seems to have lost interest before the mechanism has become ready to
> > > be integrated in the workflow commands like "am", "commit", "rebase"
> > > etc., which is unfortunate.
> > I think adding at least an option to git send-email
> > allowing auto-cc's for all
> > 	"<foo>-by: [name] <address>"
> > lines in the commit log would be useful.
> > 
> > Today, only "Signed-off-by" and "CC" lines are
> > added to cc's.
> > 
> > I've always called these lines "-by:" lines
> > "signatures", but perhaps there's a better name.
> I think we casually call them footers (as they are counter-part to
> "headers"), or trailers.

I think they are neither footers, which would relate
more to the email headers, nor trailers.

Maybe something like traces or chains.

btw: I submitted this awhile ago

http://www.spinics.net/lists/git/msg162269.html

Re: git am and duplicate signatures

[Joe Perches]

On Tue, 2016-08-30 at 10:41 -0700, Joe Perches wrote:
> Maybe something like traces or chains.

Or "taggers" or "tagged-bys"

Re: git am and duplicate signatures

[Junio C Hamano]

Joe Perches <joe@perches.com> writes:

> On Tue, 2016-08-30 at 10:41 -0700, Joe Perches wrote:
>> Maybe something like traces or chains.
>
> Or "taggers" or "tagged-bys"

I am afraid that you are way too late; the ship has already sailed a
few years ago, if not earlier, I think.

Re: git am and duplicate signatures

[Joe Perches]

On Tue, 2016-08-30 at 11:17 -0700, Junio C Hamano wrote:
> Joe Perches <joe@perches.com> writes:
> 
> > 
> > On Tue, 2016-08-30 at 10:41 -0700, Joe Perches wrote:
> > > 
> > > Maybe something like traces or chains.
> > Or "taggers" or "tagged-bys"
> I am afraid that you are way too late; the ship has already sailed a
> few years ago, if not earlier, I think.

What's the ship's name?  Is it footers or trailers?

Re: git am and duplicate signatures

[Junio C Hamano]

Joe Perches <joe@perches.com> writes:

> On Tue, 2016-08-30 at 11:17 -0700, Junio C Hamano wrote:
>> Joe Perches <joe@perches.com> writes:
>> 
>> > 
>> > On Tue, 2016-08-30 at 10:41 -0700, Joe Perches wrote:
>> > > 
>> > > Maybe something like traces or chains.
>> > Or "taggers" or "tagged-bys"
>> I am afraid that you are way too late; the ship has already sailed a
>> few years ago, if not earlier, I think.
>
> What's the ship's name?  Is it footers or trailers?

I think we casually call them footers (as they are counter-part to
"headers"), or trailers (probably more official as that is half of
the name of the subsystem that is supposed to deal with them).