From: D. Ben Knoble Date: Tue, 21 Oct 2025 21:36:31 GMT Subject: Re: [rfc] flip rerere.enabled default to be "on" at Git 3.0 boundary? Message-ID: In-Reply-To: On Tue, Oct 21, 2025 at 2:56 PM Kristoffer Haugsbakk 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.)