"Phillip Wood via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > From: Phillip Wood <phillip.wood@xxxxxxxxxxxxx> > > If the user skips the final commit by removing all the changes from > the index and worktree with 'git restore' (or read-tree) and then runs > 'git rebase --continue' .git/MERGE_MSG is left behind. This will seed > the commit message the next time the user commits which is not what we > want to happen. I just remembered that "git rebase --skip" option exists. Would it have the same issue if used at the last step? [Footnote] I am not saying that it is an error to use "git restore HEAD . && git rebase --continue" when you'd usually use "git rebase --skip". Nuking the difference the working tree files and the index has relative to HEAD and telling the machinery to continue gives the signal that the "conflict resolution" happened to have resulted in an empty change, which should yield the same resulting history as "git rebase --skip" would, because the resulting empty change should be dropped (unless --empty=keep is in effect, that is).
