git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
D. Ben Knoble <ben.knoble@gmail.com>
Date
Oct 23, 2025, 19:19 UTC
Message-ID
<CALnO6CB3EZkAyc_fWdU+P_MLcipZ4T90RSk0+46Fc20OmWEpmQ@mail.gmail.com>
In-Reply-To
<xmqqsefaydfg.fsf@gitster.g>

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
Previous: Junio C HamanoNext: Junio C Hamano
Message 9 of 12 in “[rfc] flip rerere.enabled default to be "on" at Git 3.0 boundary?”
  1. Junio C HamanoOct 21, 2025
  2. Kristoffer HaugsbakkOct 21, 2025
  3. D. Ben KnobleOct 21, 2025
  4. D. Ben KnobleOct 21, 2025
  5. Junio C HamanoOct 21, 2025
  6. Johannes SixtOct 22, 2025
  7. Ben KnobleOct 22, 2025
  8. Junio C HamanoOct 22, 2025
  9. D. Ben KnobleOct 23, 2025
  10. Junio C HamanoOct 23, 2025
  11. Ben KnobleOct 23, 2025
  12. Taylor BlauOct 21, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.