Giuseppe Bilotta <giuseppe.bilotta@xxxxxxxxx> writes: > On Mon, Jan 23, 2017 at 9:16 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Giuseppe Bilotta <giuseppe.bilotta@xxxxxxxxx> writes: >> >>> On Mon, Jan 23, 2017 at 7:13 PM, Junio C Hamano <gitster@xxxxxxxxx> 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.