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

From: Johannes Sixt <j6t@kdbg.org>
Date: Oct 22, 2025, 05:55 UTC
Message-ID: <bec27479-c53f-472c-87c7-374321108ad5@kdbg.org>
In-Reply-To: <ecf21e8d-acff-47fb-b972-59cd7b8f3146@app.fastmail.com>

Am 21.10.25 um 20:55 schrieb Kristoffer Haugsbakk:

Show 13 quoted lines

> 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.

Show 11 quoted lines

> 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.

Instead of 5.+6., do `git checkout --merge <file>`.

> 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