From: Junio C Hamano <gitster@pobox.com>
To: Joe Perches <joe@perches.com>
Cc: git <git@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: git am and duplicate signatures
Date: Tue, 30 Aug 2016 10:37:10 -0700 [thread overview]
Message-ID: <xmqq4m625fax.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <1472576869.5512.98.camel@perches.com> (Joe Perches's message of "Tue, 30 Aug 2016 10:07:49 -0700")
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.
prev parent reply other threads:[~2016-08-30 17:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[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 message]
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=xmqq4m625fax.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
/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