Sam Kuper <sam.kuper@xxxxxxxxxxx> 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.
