Johannes Schindelin <johannes.schindelin@xxxxxx> writes:
> When an interactive rebase is interrupted, the user may stage changes
> before continuing, and we need to commit those changes in that case.
>
> Please note that the nested "if" added to the sequencer_continue() is
> not combined into a single "if" because it will be extended with an
> "else" clause in a later patch in this patch series.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx>
> ---
> sequencer.c | 40 ++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 40 insertions(+)
>
> diff --git a/sequencer.c b/sequencer.c
> index 80469b6954..855d3ba503 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -1829,6 +1829,42 @@ static int continue_single_pick(void)
> return run_command_v_opt(argv, RUN_GIT_CMD);
> }
>
> +static int commit_staged_changes(struct replay_opts *opts)
> +{
> + int amend = 0;
> +
> + if (has_unstaged_changes(1))
> + return error(_("cannot rebase: You have unstaged changes."));
The scripted one from 'master' seems to say
$path_to_the_file: needs update
You must edit all merge conflicts and then
mark them as resolved using git add
when editing an existing commit in this case. The updated message
looks more sensible for the situation, but I wonder if the control
should even reach at this point.
One bad thing about reviewing this series is that all the comments
are about codepaths that are not exercised, so they cannot be more
than "they look good". A comment "If the caller does X, this will
be better than the original" (or this will regress, for that matter)
cannot be validated for its relevance because we won't know the what
the caller does in the endgame while reviewing these earlier steps.