From: Johannes Sixt Date: Wed, 22 Oct 2025 05:55:02 GMT Subject: Re: [rfc] flip rerere.enabled default to be "on" at Git 3.0 boundary? Message-ID: In-Reply-To: Am 21.10.25 um 20:55 schrieb Kristoffer Haugsbakk: > 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. While I agree that the rerere cache is a very valuable tool to have, it has the very sharp edge that a cached wrong resolution is extremely difficult to get rid of. Merge conflicts and how to resolve them correctly is a skill that needs to be trained. Giving a novice who is still tipping their toes into the waters of merge resolution the advice to "just enable rerere" exposes them to a behavior whose results (the reuse of incorrect merge resolutions that they thought they had already corrected) are inexplicable without the help of an expert. I think I'm saying that I am mildly opposed to enable rerere by default as long as it has this sharp edge. > 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 ` > 5. `git merge --abort` > 6. Do merge again > 7. Now I can redo the merge conflict for `` 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. Instead of 5.+6., do `git checkout --merge `. > 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. Could rerere perhaps update the cache even after a resolution has been reused? Then a reused and then modified resolution would enter the cache, and the updated resolution would be reused if and when the merge is repeated. -- Hannes