Hint: rerere doesn't always work. It's still guesswork, like the rest of merges/rebases/cherry-picking in Git. This is because looking only at the tips of branches doesn't work, and that's the only thing Git can do (with or without diff3 as the merge algorithm).

The rerere database is content-addressed, and rerere will apply a resolution only if the pair of conflicting files is a bit-exact déjà-vu of a conflict it has seen before.

I don’t see how that is guesswork. My impression is that rerere is perfectly deterministic, and only repeat things the user has done before.

The downside is: once the user has manually created a faulty resolution, then rerere will possibly replay that faulty resolution.

That’s how things can go wrong, and I see how one might blame that failure on rerere itself. And I think the blame not entirely unjustified, because rerere could do a much better job in explaining how it interacts with certain scenarios. For example, let’s say I’m aborting a rebase. Will rerere roll back the resolutions it recorded? I honestly don’t know. The manpage vaguely claims that it will, but I’ve been unable to reproduce it.

I wish rerere made more transparent how it interacts with `--abort`. Just printing an informational line would already go a long way. I also feel a command like `git rerere log`, which would print the recent activity of the `rerere` database, might help with that.