On 12/06/2018, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Sam Kuper <sam.kuper@xxxxxxxxxxx> 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
