* Re: git am and duplicate signatures
[not found] ` <xmqqwpiy5haf.fsf@gitster.mtv.corp.google.com>
@ 2016-08-30 17:07 ` Joe Perches
2016-08-30 17:37 ` Junio C Hamano
0 siblings, 1 reply; 2+ messages in thread
From: Joe Perches @ 2016-08-30 17:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, LKML
(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.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: git am and duplicate signatures
2016-08-30 17:07 ` git am and duplicate signatures Joe Perches
@ 2016-08-30 17:37 ` Junio C Hamano
0 siblings, 0 replies; 2+ messages in thread
From: Junio C Hamano @ 2016-08-30 17:37 UTC (permalink / raw)
To: Joe Perches; +Cc: git, LKML
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2016-08-30 17:37 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1472573556.5512.93.camel@perches.com>
[not found] ` <xmqqwpiy5haf.fsf@gitster.mtv.corp.google.com>
2016-08-30 17:07 ` git am and duplicate signatures Joe Perches
2016-08-30 17:37 ` Junio C Hamano
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox