Re: [PATCH] am: add am.signoff add config variable

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Dec 29, 2016 at 2:43 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Stefan Beller <sbeller@xxxxxxxxxx> 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.
--



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]