Giuseppe Bilotta <[email protected]> writes:
> On Mon, Jan 23, 2017 at 9:16 PM, Junio C Hamano <[email protected]> wrote:
>> Giuseppe Bilotta <[email protected]> writes:
>>
>>> On Mon, Jan 23, 2017 at 7:13 PM, Junio C Hamano <[email protected]> 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?
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.
