Re: [PATCH 2/2] rebase --exec: make it work with --rebase-merges

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 6, 2018, 15:12 UTC
Message-ID: <xmqqlg9jr0la.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <nycvar.QRO.7.76.6.1808061136180.71@tvgsbejvaqbjf.bet>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 10 quoted lines

>> If we ever see a todo-list without any pick/merge, then insert_final
>> is still 1 when we leave the loop and we will add one single exec at
>> the end.  Which may or may not make sense---I dunno, as I do not
>> offhand think of a reason why the user would give us such a sequence
>> in the first place, so it probably may not matter in practice.
>
> Think of the `noop` command. It was introduced specifically to allow
> rebasing patches interactively to an upstream that already applied the
> local patches. In that case, an `--exec` should still run at least once,
> to avoid negative surprises.

Ah, yes, it probably makes sense when you have `noop`; even if there is no picks and merges that change the history from previous state (which presumably matches the state the user started running the current "rebase -i" session), after the whole sequence you would want run it one iteration.

In any case, if the current code without this change works like so, there is no point in redesigning that part of the semantics at all.