Re: [PATCH v2 3/3] rebase --continue: remove .git/MERGE_MSG
- From
- Phillip Wood <phillip.wood123@gmail.com>
- Date
- Aug 14, 2021, 20:01 UTC
- Message-ID
- <549ebc1e-2b3d-786b-6467-40fb521ea0cc@gmail.com>
- In-Reply-To
- <xmqqa6lluexv.fsf@gitster.g>
On 14/08/2021 00:01, Junio C Hamano wrote:
Show 12 quoted lines
> "Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com> writes: > >> From: Phillip Wood <phillip.wood@dunelm.org.uk> >> >> 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?
--skip calls rerere_clear() which unlinks .git/MERGE_MSG. This patch adds a test for --skip as well as --continue.
Best Wishes
Phillip
Show 13 quoted lines
> > [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). >