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

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

[Junio C Hamano]

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?

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

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

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

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

[D. Ben Knoble]

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

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

[D. Ben Knoble]

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

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

[Junio C Hamano]

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:

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

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

[Johannes Sixt]

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

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

[Ben Knoble]

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

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

[Junio C Hamano]

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?

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

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

[D. Ben Knoble]

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

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

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

[Junio C Hamano]

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

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

[Ben Knoble]

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

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

[Taylor Blau]

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

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