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

>
> On Tue, Oct 21, 2025 at 2:56 PM Kristoffer Haugsbakk
> <kristofferhaugsbakk@fastmail.com> wrote:
> >
> > 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?
>
> Seconding this: it's too easy to miss the rerere messages, which can
> make other moments more confusing. (IIRC, git-status still says we
> need to "approve" the resolution, but for folks not used to rerere it
> might be obvious how to check the resolution? Idk, can't recall
> offhand.)