From: Phillip Wood Date: Thu, 27 Apr 2023 10:17:15 GMT Subject: Re: [PATCH v2 2/6] rebase -i: remove patch file after conflict resolution Message-ID: <1fd54422-b66a-c2e4-7cd7-934ea01190ad@gmail.com> In-Reply-To: On 21/04/2023 20:01, Junio C Hamano wrote: > "Phillip Wood via GitGitGadget" writes: > >> From: Phillip Wood >> >> 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"). Yes that's the reason - we don't want a stale patch when we stop for another reason, I'll improve the commit message. Best Wishes Phillip >> 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 >> --- >> 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.