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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 22, 2025, 18:54 UTC
Message-ID: <xmqqsefaydfg.fsf@gitster.g>
In-Reply-To: <80220653-7302-4E4D-99E9-1A8CB5B4F23D@gmail.com>

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.