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

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

[Sam Kuper]

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

Thanks :)

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

[Junio C Hamano]

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

> `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.

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

[Sam Kuper]

On 12/06/2018, Junio C Hamano <gitster@pobox.com> wrote:
> Sam Kuper <sam.kuper@uclmail.net> writes:
>> [...] 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 [...]
>
> 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 ;-)

Thanks, good to know.

> The command is a mere synonym to "git reset --merge";

Indeed it seems so. Thank you for pointing this out.

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

Unfortunately, I am still not familiar enough with the Git codebase to
be able to express an informed opinion about this. Sorry :(

> Doing so might allow us
> to lose calls to rerere_clear() individual codepaths of various
> "abort" implementations make,

That, I think, was an example of a garden path sentence.[1] Took me
more than one parse to understand it :)

Anyhow, yes, I agree that this might be an opportunity to DRY the
codebase in that regard. (And this would be a good thing, if so.)

> but that would certainly require
> careful thinking to avoid unintended regressions.

I don't use `git reset --merge` often enough to have formed an opinion
about whether there are any use-cases for it in which it would be
inappropriate for it to run `git rerere clear`. Apologies again not to
be able to be more helpful. I hope that you or others on the list will
be able to consider this matter, and the question of how/where to best
implement the change.

Thank you for your work maintaining Git!

[1] https://en.wikipedia.org/wiki/Garden_path_sentence