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