threads / rfc / 64364

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

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

## tl;dr

12 messages between Oct 21, 2025 and Oct 23, 2025.

replies: 11people: 5as markdown or json

Junio C Hamano· Oct 21, 2025, 18:21 UTC · lore

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?
Kristoffer Haugsbakk· Oct 21, 2025, 18:55 UTC · re: Junio C Hamano · lore

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

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
D. Ben Knoble· Oct 21, 2025, 21:36 UTC · re: Kristoffer Haugsbakk · lore

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:

Show 36 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.
>
> 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.)

D. Ben Knoble· Oct 21, 2025, 21:37 UTC · re: D. Ben Knoble · lore

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

On Tue, Oct 21, 2025 at 5:36 PM D. Ben Knoble <ben.knoble@gmail.com> wrote:
Show 45 quoted lines
>
> 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.)

Premature send—the above said, I don't think it's anything against graduating rerere to default. Just that there will be some more edges to polish, which is a good thing.

-- 
D. Ben Knoble
Junio C Hamano· Oct 21, 2025, 22:19 UTC · re: Kristoffer Haugsbakk · lore

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

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
Show 20 quoted lines
> 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.

That is how I would do it. Of course if I know I can get to the right resolution without steps 5 and 6, then I'd just record the resolution after doing "rerere forget" at step 4.

Johannes Sixt· Oct 22, 2025, 05:55 UTC · re: Kristoffer Haugsbakk · lore

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

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
Ben Knoble· Oct 22, 2025, 17:45 UTC · re: Johannes Sixt · lore

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

Show 30 quoted lines
> Le 22 oct. 2025 à 01:55, Johannes Sixt <j6t@kdbg.org> a écrit :
> 
> 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.
Fair points. Could I ask an enterprising reader to summarize the sharp edges of rerere that need polished? It could make an effective todo list to aim for prior to 3.0. Here’s what I recall seeing:
- messaging is not clear
- usage for dealing with incorrect caches needs improvement (should be useable without expert intervention)
    - as a first step, perhaps having rerere and status display more information about possible steps to take (review results, keep or discard) would help?
Junio C Hamano· Oct 22, 2025, 18:54 UTC · re: Ben Knoble · lore

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

Ben Knoble <ben.knoble@gmail.com> writes:
Show 7 quoted lines
>> I think I'm saying that I am mildly opposed to enable rerere by default
>> as long as it has this sharp edge.
>
> Fair points. Could I ask an enterprising reader to summarize the sharp edges of rerere that need polished? It could make an effective todo list to aim for prior to 3.0. Here’s what I recall seeing:
> - messaging is not clear
> - usage for dealing with incorrect caches needs improvement (should be useable without expert intervention)
>     - as a first step, perhaps having rerere and status display more information about possible steps to take (review results, keep or discard) would help?
- delete/modify conflicts are not recorded and replayed due to
  safety concerns [*], but in practice, most of the time it seems
  that the user wishes to re-resolve such a conflict to 'delete' the
  path.
[Footnote]
 * The modification that is safe to discard when resolving the
   conflict to remove the path today may not apply if the
   modification to the path that is deleted is different and may
   require a different resolution other than discarding it.
D. Ben Knoble· Oct 23, 2025, 19:19 UTC · re: Junio C Hamano · lore

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

I think I'm confused, which is probably on my end, but let me try to clear up what I wrote, at least.

On Wed, Oct 22, 2025 at 2:55 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 10 quoted lines
>
> Ben Knoble <ben.knoble@gmail.com> writes:
>
> >> I think I'm saying that I am mildly opposed to enable rerere by default
> >> as long as it has this sharp edge.
> >
> > Fair points. Could I ask an enterprising reader to summarize the sharp edges of rerere that need polished? It could make an effective todo list to aim for prior to 3.0. Here’s what I recall seeing:
> > - messaging is not clear
> > - usage for dealing with incorrect caches needs improvement (should be useable without expert intervention)
> >     - as a first step, perhaps having rerere and status display more information about possible steps to take (review results, keep or discard) would help?
[On the chance that the reply was due to this wording]

Here, "keep or discard" were meant as possible actions to take on the rerere resolution. Something like

git status … file (recorded resolution reused) … hint: To review the reused resolutions, run X hint: To discard them, run Y hint: Concluding the merge without discarding them will keep them.

or some such.
Show 11 quoted lines
> - delete/modify conflicts are not recorded and replayed due to
>   safety concerns [*], but in practice, most of the time it seems
>   that the user wishes to re-resolve such a conflict to 'delete' the
>   path.
>
> [Footnote]
>
>  * The modification that is safe to discard when resolving the
>    conflict to remove the path today may not apply if the
>    modification to the path that is deleted is different and may
>    require a different resolution other than discarding it.

Was this intended as "another todo list item to work on"? If so, I'm afraid I'm having trouble decoding what the issue that needs fixed is. My nth re-read suggests that the sharp edge here is "delete/modify conflicts often need re-resolution favoring delete" and that doing so is not easy today?

-- 
D. Ben Knoble
Junio C Hamano· Oct 23, 2025, 19:44 UTC · re: D. Ben Knoble · lore

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

"D. Ben Knoble" <ben.knoble@gmail.com> writes:
Show 5 quoted lines
> Was this intended as "another todo list item to work on"? If so, I'm
> afraid I'm having trouble decoding what the issue that needs fixed is.
> My nth re-read suggests that the sharp edge here is "delete/modify
> conflicts often need re-resolution favoring delete" and that doing so
> is not easy today?

It meant to add to the list another sharp-edge, which is that 'rerere' does not even attempt to help you deal with delete-modify conflicts at all. Either it needs to be communicated better that the users are on their own with delete-modify conflicts, or a good support needs to be designed and documented.

Ben Knoble· Oct 23, 2025, 22:03 UTC · re: Junio C Hamano · lore

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

Show 15 quoted lines
> Le 23 oct. 2025 à 15:44, Junio C Hamano <gitster@pobox.com> a écrit :
> 
> "D. Ben Knoble" <ben.knoble@gmail.com> writes:
> 
>> Was this intended as "another todo list item to work on"? If so, I'm
>> afraid I'm having trouble decoding what the issue that needs fixed is.
>> My nth re-read suggests that the sharp edge here is "delete/modify
>> conflicts often need re-resolution favoring delete" and that doing so
>> is not easy today?
> 
> It meant to add to the list another sharp-edge, which is that
> 'rerere' does not even attempt to help you deal with delete-modify
> conflicts at all.  Either it needs to be communicated better that
> the users are on their own with delete-modify conflicts, or a good
> support needs to be designed and documented.
Thanks!
Taylor Blau· Oct 21, 2025, 19:45 UTC · re: Junio C Hamano · lore

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

On Tue, Oct 21, 2025 at 11:21:46AM -0700, 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?

Perhaps, but I wonder if waiting until Git 3.0 is necessary. I use the rerere cache daily and have for years, so I consider this battle-tested at least in my own workflow.

I'm not saying we should *necessarily* do this, but I wonder for argument's sake: what would prevent us from changing the default for 2.52?

Thanks, Taylor

← back to recent threads