Johannes Schindelin <johannes.schindelin@xxxxxx> writes:
> When doing an interactive rebase, we want to leave a 'patch' file for
> further inspection by the user (even if we never tried to actually apply
> that patch, since we're cherry-picking instead).
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx>
> ---
Yup.
The other day, I was kind of surprised to see the "patch" file
produced when I tried to do "git rebase -i HEAD^^ HEAD" with the one
in current Git (not yours), marked the first one "edit", and then it
gave me control back. Obviously there was no conflict and I could
just do "git show" if I wanted to see what the original change was,
but the "patch" file was there. I personally never have looked at
the "patch" file in such a situation, and I kind of feel it is
wasteful, but I can see people expect to find one there whenever
"rebase -i" stops and gives control back. It is good that you are
preserving the behaviour.
> sequencer.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/sequencer.c b/sequencer.c
> index a4e9b326ba..4361fe0e94 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -1777,6 +1777,9 @@ static int pick_commits(struct todo_list *todo_list, struct replay_opts *opts)
> return error_failed_squash(item->commit, opts,
> item->arg_len, item->arg);
> }
> + else if (res && is_rebase_i(opts))
> + return res | error_with_patch(item->commit,
> + item->arg, item->arg_len, opts, res, 0);
> }
> else if (item->command == TODO_EXEC) {
> char *end_of_arg = (char *)(item->arg + item->arg_len);