Re: [PATCH v2 2/6] rebase -i: remove patch file after conflict resolution

[Junio C Hamano <gitster@pobox.com>]

"Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Phillip Wood <phillip.wood@dunelm.org.uk>
>
> When rebase stops for the user to resolve conflicts it writes a patch
> for the conflicting commit to .git/rebase-merge/patch. This file
> should be deleted when the rebase continues.

Could you describe the reason why this file "should" be deleted a
bit better?  Once the user edits the files in the working tree and
tell "git rebase" with the "--continue" option that they finished
helping the command, and the command creates a commit out of the
resolution left by the user in the working tree and in the index,
the patch may no longer is needed, so I can understand if this were
"this file can be deleted"---in other words, again, this explains
why such a change would not be a wrong change that hurts the users,
but it does not explain why we want such a change very well.  Is
there a reason why a left-over patch file is a bad thing (perhaps
causing end-user confusion upon seeing such a patch that apparently
is for a much earlier step in the rebase in progress?  If so, that
might be a good justification to say we "should").

> As the path is now used
> in two different places rebase_path_patch() is added and used to
> obtain the path for the patch.

OK.

> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
> ---
>  sequencer.c | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)

The patch text itself looks good in the sense that it correctly
implements what the proposed log message claims it "should".

Thanks.