From: Stefan Beller <sbeller@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Eric Wong <e@80x24.org>, Eduardo Habkost <ehabkost@redhat.com>,
"git@vger.kernel.org" <git@vger.kernel.org>,
Paul Tan <pyokagan@gmail.com>
Subject: Re: [PATCH] am: add am.signoff add config variable
Date: Thu, 29 Dec 2016 15:34:51 -0800 [thread overview]
Message-ID: <CAGZ79kZFCDiYt6q52t5XMw0aB2qHA9ODVkCQJSxrGckSV3+O8A@mail.gmail.com> (raw)
In-Reply-To: <xmqqpoka5pb0.fsf@gitster.mtv.corp.google.com>
On Thu, Dec 29, 2016 at 2:43 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Stefan Beller <sbeller@google.com> writes:
>
>>> IANAL either, but we have been striving to keep output of
>>>
>>> $ git grep '\.signoff' Documentation
>>
>>>
>>> empty to keep Sign-off meaningful.
>>
>> Try again with -i ;)
>> and you'll find format.signOff
>
> Mistakes happen. Finding an old mistake is not an excuse for you to
> make the same one again.
> It is an opportunity to come up with a way
> to correct it without hurting existing users by designing a smooth
> transition path.
>
knee jerk reaction:
1) Document why format.signoff is bad (even after a long
office discussion I am not fully convinced it is bad. That
may be because I am biased as I find format.signoff *very*
useful. The cumbersome contribution process as laid out
by SubmittingPatches just got easier for me as I have one
step less to worry about. I haven't made a mistake so far
sending out crap where I'll throw a temper tantrum if you
apply it.
So I would expect a maintainer of a project that uses
email based workflow to write that documentation giving
reasons. That person is currently consuming the automatically
signed off patches, so I'd want to know their line of thinking.
2) If the config option is set, but no explicit sign off is given,
put a different footer, e.g.
git config format.signoff true &&
git format-patch HEAD^
may produce Auto-Signed-Off-By: ...
whereas
git -c format.signoff format-patch
behaves the same as
git format-patch --signoff
that gives the Signed-Off-By as we know it.
It is up to the upstream project to accept these new sign offs.
3) (later) warn about the option if it is set, giving the text from 1)
4) (a long time later) remove the option.
--
For 2) I am not sure what we want there, because this
has to happen in collaboration with all the upstream projects that
use sign offs.
We could be subtle, i.e. just use all lowercase / all uppercase
letters for this differentiation. Then automated tools that check for signoff
are easily adjusted. e.g. The eclipse foundation disallows pushing for
review if any patch is missing a signoff; Gerrit can check for that.
Gerrit is not case sensitive when checking for a footer.
I am not sure if there are any other tools out there that automatically
check for that, but I would assume they are also case insensitive in
such a case, as it is unclear to me how to properly capitalize the sign off.
This is an easy way forward for upstream projects., though confusing in
court later on.
--
We could also be non-subtle, very explicit, and each tool that
can add sign offs currently, needs to be explicit about itself:
Configured-Formatpatch-Signed-Off: (for git format.signoff with config)
# and others:
Explicit-Formatpatch-Signed-Off:
Git-Gui-Button-Clicked-Signed-Off:
Git-Gui-Button-Shortcut-Signed-Off:
Once we have that we could add much more of these:
Configured-Commit-Signed-Off:
etc.
You can continue to sign off via just typing it, or by
I-typed-it-signed-Off,
--
One of the problems highlighted to me was that you could have accidentally
configured format.signoff globally, but you're only allowed/desire to sign off
in a particular repository, such that
Repolocal-Configured-Formatpatch-Signed-Off:
Global-Configured-Formatpatch-Signed-Off:
may be worth discussing.
--
prev parent reply other threads:[~2016-12-29 23:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-28 17:40 [PATCH] am: add am.signoff add config variable Eduardo Habkost
2016-12-28 17:45 ` Stefan Beller
2016-12-28 17:50 ` Eduardo Habkost
2016-12-29 8:47 ` Eric Wong
2016-12-29 15:45 ` Eduardo Habkost
2016-12-29 17:49 ` Jacob Keller
2016-12-29 21:42 ` Junio C Hamano
2016-12-29 22:16 ` Eduardo Habkost
2016-12-29 22:18 ` Stefan Beller
2016-12-29 22:43 ` Junio C Hamano
2016-12-29 23:34 ` Stefan Beller [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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGZ79kZFCDiYt6q52t5XMw0aB2qHA9ODVkCQJSxrGckSV3+O8A@mail.gmail.com \
--to=sbeller@google.com \
--cc=e@80x24.org \
--cc=ehabkost@redhat.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pyokagan@gmail.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).