Re: [PATCH v2 3/3] rebase --continue: remove .git/MERGE_MSG

From: Junio C Hamano <gitster@pobox.com>
To: "Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Phillip Wood <phillip.wood123@gmail.com>,
	Phillip Wood <phillip.wood@dunelm.org.uk>
Subject: Re: [PATCH v2 3/3] rebase --continue: remove .git/MERGE_MSG
Date: Fri, 13 Aug 2021 16:01:48 -0700	[thread overview]
Message-ID: <xmqqa6lluexv.fsf@gitster.g> (raw)
In-Reply-To: <028c9dfc460b6c00bf481017a07a2a6d37780a76.1628775729.git.gitgitgadget@gmail.com> (Phillip Wood via GitGitGadget's message of "Thu, 12 Aug 2021 13:42:09 +0000")

"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?

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