Re: [rfc] flip rerere.enabled default to be "on" at Git 3.0 boundary?

["Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com>]

On Tue, Oct 21, 2025, at 20:21, Junio C Hamano wrote:
> A good default matters, and people who find out how useful a rerere
> database is would say "gee, that sounds great but why they do not
> enable it by default?  It is too buggy and they wanted to reduce the
> number of support requests?"  Yes, the reason it is not enabled by
> default initially was exactly that, i.e. those opt into the feature
> was used as guinea pigs to polish the feature.  But we forgot to set
> the graduation criteria and never said "ok it is mature enough, so
> let's turn it on for everybody".
>
> Perhaps Git 3.0 boundary is a good occasion to do so?

This sounds nice.

Sometimes I make bad resolutions and my cache gets in the way.  But I
know it’s a directory or file somewhere that I can delete manually.  So
that’s nice.  And if I didn’t know I think I could have found it on
StackOverflow.

I don’t think the “reused resolution” is super clear for things like
rebase and merge.  I will get output like

      CONFLICT
      CONFLICT
      CONFLICT
      Reused recorded resolution for ...
      Reused recorded resolution for ...
      Reused recorded resolution for ...
      YOUR STUFF IS CONFLICTED
      DO THIS AND THAT

      this is from memory :p

And the “reused” messages are kind of “randomly” placed in the stderr
stream of consciousness.  Could they be colored maybe?

The biggest usability problem for me is when I have a cache, I want to
keep it, but I want to remove a few pathspecs.  I’ve made some notes on
this to myself.  Apparently I tried to `git rerere forget` on some paths
but I got not output.  Then I did it again and it reused it. According
to my notes I had to get into that conflict resolution state and then
*forget*:

(this is straight from my notes, I didn’t try this right now)

1. I did the wrong thing for `file`
2. I reset the merge back
3. I did the merge
4. *While resolving conflicts*: `git rerere forget <file>`
5. `git merge --abort`
6. Do merge again
7. Now I can redo the merge conflict for `<file>` while keeping the rest
   of the resolutions

I don’t know if all of that was necessary but that’s what I did to make
it work for me.

In short I guess I’m saying that git-rerere(1) isn’t that
straightforward if you want to figure out what is in the cache, if you
can delete things from it in your current state, things like that.

(Contrast with git-reflog(1) which is great to always have available;
copying hashes from the reflog to reset or something might be obtuse to
some people, but the reflog is never in the way, you can always look at
it, and you don’t have to worry about selectively deleting/pruning it.)

I’ve tried to read Junio’s old blog post about rerere pitfalls but I was
never able to understand it. (I’m not soliciting anyone to explain it to
me, just saying.)

For people with *my* biases towards rewriting history it sounds like a
good default. But I think for those users who make twenty merges in
either direction before they land their changes in the “main” branch it
probably won’t matter at all.

Just some thoughts. I won’t be able to follow up on this thread.

--
Kristoffer

Probably away until 28th October