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

[Sam Kuper <sam.kuper@uclmail.net>]

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