On 21/04/2023 20:01, Junio C Hamano wrote:
"Phillip Wood via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
From: Phillip Wood <phillip.wood@xxxxxxxxxxxxx>
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 <phillip.wood@xxxxxxxxxxxxx>
---
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.
