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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 21, 2023, 19:01 UTC
Message-ID: <xmqqwn25jbzw.fsf@gitster.g>
In-Reply-To: <227aea031b588977f22f3f97faee981d79ade05c.1682089074.git.gitgitgadget@gmail.com>

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

Show 5 quoted lines

> 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.