patchrebase: pass --signoff option to git am

> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
>  Documentation/git-rebase.txt | 5 +++++
>  git-rebase.sh                | 3 ++-
>  2 files changed, 7 insertions(+), 1 deletion(-)

> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> index 67d48e6883..e6f0b93337 100644
> --- a/Documentation/git-rebase.txt
> +++ b/Documentation/git-rebase.txt
> @@ -385,6 +385,11 @@ have the long commit hash prepended to the format.
>  	Recreate merge commits instead of flattening the history by replaying
>  	commits a merge commit introduces. Merge conflict resolutions or manual
>  	amendments to merge commits are not preserved.
> +
> +--signoff::
> +	This flag is passed to 'git am' to sign off all the rebased
> +	commits (see linkgit:git-am[1]).
> +
>  +
>  This uses the `--interactive` machinery internally, but combining it
>  with the `--interactive` option explicitly is generally not a good
> diff --git a/git-rebase.sh b/git-rebase.sh
> index 48d7c5ded4..e468a061f9 100755
> --- a/git-rebase.sh
> +++ b/git-rebase.sh
> @@ -34,6 +34,7 @@
>  autosquash         move commits that begin with squash!/fixup! under -i
>  committer-date-is-author-date! passed to 'git am'
>  ignore-date!       passed to 'git am'
> +signoff!           passed to 'git am'
>  whitespace=!       passed to 'git apply'
>  ignore-whitespace! passed to 'git apply'
>  C=!                passed to 'git apply'
> @@ -321,7 +322,7 @@ run_pre_rebase_hook ()
>  	--ignore-whitespace)
>  		git_am_opt="$git_am_opt $1"
>  		;;
> -	--committer-date-is-author-date|--ignore-date)
> +	--committer-date-is-author-date|--ignore-date|--signoff)
>  		git_am_opt="$git_am_opt $1"
>  		force_rebase=t
>  		;;

> On Mon, Jan 23, 2017 at 7:13 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Should we plan to extend this to the interactive backend that is
>> shared between rebase -i and rebase -m, too?  Or is this patch
>> already sufficient to cover them?
>
> AFAIK this is sufficient for both, in the sense that I've used it with
> git rebase -i and it works.

> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>
>> On Mon, Jan 23, 2017 at 7:13 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>>
>>> Should we plan to extend this to the interactive backend that is
>>> shared between rebase -i and rebase -m, too?  Or is this patch
>>> already sufficient to cover them?
>>
>> AFAIK this is sufficient for both, in the sense that I've used it with
>> git rebase -i and it works.
>
> That is a good news and at the same time a bit awkard one ;-)
>
> The mention of "passed to 'git am'" twice in the documentation and
> help text would lead people to think "rebase -i" would not be
> affected and (1) would need more work to do so, or (2) the user does
> not want "rebase -i" to be unaffected for whatever reason, and gets
> surprised to see that it actually does get affected.

> On Mon, Jan 23, 2017 at 9:16 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>>
>>> On Mon, Jan 23, 2017 at 7:13 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>>>
>>>> Should we plan to extend this to the interactive backend that is
>>>> shared between rebase -i and rebase -m, too?  Or is this patch
>>>> already sufficient to cover them?
>>>
>>> AFAIK this is sufficient for both, in the sense that I've used it with
>>> git rebase -i and it works.
>>
>> That is a good news and at the same time a bit awkard one ;-)
>>
>> The mention of "passed to 'git am'" twice in the documentation and
>> help text would lead people to think "rebase -i" would not be
>> affected and (1) would need more work to do so, or (2) the user does
>> not want "rebase -i" to be unaffected for whatever reason, and gets
>> surprised to see that it actually does get affected.
>
> I'm not sure I follow. If the user doesn't want to signoff during a
> rebase, they can simply not pass --signoff. If they do, they can not
> pass it. Am I missing something?

>
>> In any case, will queue as-is so that we won't lose the patch while
>> waiting for people to raise their opinions.
>
> Thanks.

> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>>
>> I'm not sure I follow. If the user doesn't want to signoff during a
>> rebase, they can simply not pass --signoff. If they do, they can not
>> pass it. Am I missing something?
>
> alias.
>
> Which also means that there needs to be --no-signoff option that can
> be given to countermand an earlier --signoff, if a user did
>
>         [alias] rb = rebase --signoff
>
> and wants to disable it one time only with
>
>         $ git rb --no-signoff

>>> In any case, will queue as-is so that we won't lose the patch while
>>> waiting for people to raise their opinions.
>>
>> Thanks.
>
> Thanks.  The final version would also need tests, so it may be a
> good time to start thinking about what aspect of this feature wants
> to be protected against future breakages.

> On Mon, Jan 23, 2017 at 7:13 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Should we plan to extend this to the interactive backend that is
>> shared between rebase -i and rebase -m, too?  Or is this patch
>> already sufficient to cover them?
>
> AFAIK this is sufficient for both, in the sense that I've used it with
> git rebase -i and it works.