From: D. Ben Knoble Date: Thu, 23 Oct 2025 19:19:57 GMT Subject: Re: [rfc] flip rerere.enabled default to be "on" at Git 3.0 boundary? Message-ID: In-Reply-To: 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 wrote: > > Ben Knoble 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