Re: `git merge --abort` does not run `git rerere clear`

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 12, 2018, 19:52 UTC
Message-ID: <xmqqr2lb9406.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CAD-JurLXh=rOC=bhjTa8jCpeDWkbDhCztSpjLuMEUGm1-QnAiw@mail.gmail.com>

Sam Kuper <sam.kuper@uclmail.net> writes:

Show 16 quoted lines

> `man git-rerere` says:
>
>> clear
>>
>> Reset the metadata used by rerere if a merge resolution is to be
>> aborted. Calling git am [--skip|--abort] or git rebase
>> [--skip|--abort] will automatically invoke this command.
>
> It makes sense that `git am [--skip|--abort]` and `git rebase
> [--skip|--abort]` would run `git rerere clear`.
>
> However, if they run it, then shouldn't `git merge --abort` run it, too?
>
> If not, then what is the reason why not, and might it be helpful for
> this reason to be mentioned at some appropriate place in the
> documentation?

I do not think there was any reason, other than that those who added "git merge --abort" weren't as careful as they should have been ;-)

The command is a mere synonym to "git reset --merge"; I am not so confident that "git reset --merge" should also clear the current rerere state. If (and this is a big if) "git reset --merge" should, probably the right place to do so would be remove_branch_state(), before the function removes merge_rr file. Doing so might allow us to lose calls to rerere_clear() individual codepaths of various "abort" implementations make, but that would certainly require careful thinking to avoid unintended regressions.