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

From: Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>
Date: Oct 21, 2025, 18:55 UTC
Message-ID: <ecf21e8d-acff-47fb-b972-59cd7b8f3146@app.fastmail.com>
In-Reply-To: <xmqqldl4und1.fsf@gitster.g>

On Tue, Oct 21, 2025, at 20:21, Junio C Hamano wrote:

Show 10 quoted lines

> 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