{"thread":{"id":"64364","subject":"[rfc] flip rerere.enabled default to be \"on\" at Git 3.0 boundary?","startedAt":"2025-10-21T18:21:48Z","lastAt":"2025-10-23T22:03:24Z","messageCount":12,"participants":["Junio C Hamano","Kristoffer Haugsbakk","Taylor Blau","D. Ben Knoble","Johannes Sixt","Ben Knoble"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"529310","messageId":"xmqqldl4und1.fsf@gitster.g","threadId":"64364","inReplyTo":null,"subject":"[rfc] flip rerere.enabled default to be \"on\" at Git 3.0 boundary?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-21T18:21:46Z","receivedAt":"2025-10-21T18:21:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"A good default matters, and people who find out how useful a rerere\ndatabase is would say \"gee, that sounds great but why they do not\nenable it by default? It is too buggy and they wanted to reduce the\nnumber of support requests?\" Yes, the reason it is not enabled by\ndefault initially was exactly that, i.e. those opt into the feature\nwas used as guinea pigs to polish the feature. But we forgot to set\nthe graduation criteria and never said \"ok it is mature enough, so\nlet's turn it on for everybody\".\n\nPerhaps Git 3.0 boundary is a good occasion to do so?\n"},{"id":"529320","messageId":"ecf21e8d-acff-47fb-b972-59cd7b8f3146@app.fastmail.com","threadId":"64364","inReplyTo":"xmqqldl4und1.fsf@gitster.g","subject":"Re: [rfc] flip rerere.enabled default to be \"on\" at Git 3.0 boundary?","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-10-21T18:55:47Z","receivedAt":"2025-10-21T18:56:19Z","isPatch":false,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Tue, Oct 21, 2025, at 20:21, Junio C Hamano wrote:\n> A good default matters, and people who find out how useful a rerere\n> database is would say \"gee, that sounds great but why they do not\n> enable it by default? It is too buggy and they wanted to reduce the\n> number of support requests?\" Yes, the reason it is not enabled by\n> default initially was exactly that, i.e. those opt into the feature\n> was used as guinea pigs to polish the feature. But we forgot to set\n> the graduation criteria and never said \"ok it is mature enough, so\n> let's turn it on for everybody\".\n>\n> Perhaps Git 3.0 boundary is a good occasion to do so?\n\nThis sounds nice.\n\nSometimes I make bad resolutions and my cache gets in the way. But I\nknow it’s a directory or file somewhere that I can delete manually. So\nthat’s nice. And if I didn’t know I think I could have found it on\nStackOverflow.\n\nI don’t think the “reused resolution” is super clear for things like\nrebase and merge. I will get output like\n\n CONFLICT\n CONFLICT\n CONFLICT\n Reused recorded resolution for ...\n Reused recorded resolution for ...\n Reused recorded resolution for ...\n YOUR STUFF IS CONFLICTED\n DO THIS AND THAT\n\n this is from memory :p\n\nAnd the “reused” messages are kind of “randomly” placed in the stderr\nstream of consciousness. Could they be colored maybe?\n\nThe biggest usability problem for me is when I have a cache, I want to\nkeep it, but I want to remove a few pathspecs. I’ve made some notes on\nthis to myself. Apparently I tried to `git rerere forget` on some paths\nbut I got not output. Then I did it again and it reused it. According\nto my notes I had to get into that conflict resolution state and then\n*forget*:\n\n(this is straight from my notes, I didn’t try this right now)\n\n1. I did the wrong thing for `file`\n2. I reset the merge back\n3. I did the merge\n4. *While resolving conflicts*: `git rerere forget `\n5. `git merge --abort`\n6. Do merge again\n7. Now I can redo the merge conflict for `` while keeping the rest\n of the resolutions\n\nI don’t know if all of that was necessary but that’s what I did to make\nit work for me.\n\nIn short I guess I’m saying that git-rerere(1) isn’t that\nstraightforward if you want to figure out what is in the cache, if you\ncan delete things from it in your current state, things like that.\n\n(Contrast with git-reflog(1) which is great to always have available;\ncopying hashes from the reflog to reset or something might be obtuse to\nsome people, but the reflog is never in the way, you can always look at\nit, and you don’t have to worry about selectively deleting/pruning it.)\n\nI’ve tried to read Junio’s old blog post about rerere pitfalls but I was\nnever able to understand it. (I’m not soliciting anyone to explain it to\nme, just saying.)\n\nFor people with *my* biases towards rewriting history it sounds like a\ngood default. But I think for those users who make twenty merges in\neither direction before they land their changes in the “main” branch it\nprobably won’t matter at all.\n\nJust some thoughts. I won’t be able to follow up on this thread.\n\n--\nKristoffer\n\nProbably away until 28th October\n"},{"id":"529321","messageId":"aPfi3JuQsDS9mpN0@nand.local","threadId":"64364","inReplyTo":"xmqqldl4und1.fsf@gitster.g","subject":"Re: [rfc] flip rerere.enabled default to be \"on\" at Git 3.0 boundary?","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2025-10-21T19:45:32Z","receivedAt":"2025-10-21T19:45:35Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Tue, Oct 21, 2025 at 11:21:46AM -0700, Junio C Hamano wrote:\n> A good default matters, and people who find out how useful a rerere\n> database is would say \"gee, that sounds great but why they do not\n> enable it by default? It is too buggy and they wanted to reduce the\n> number of support requests?\" Yes, the reason it is not enabled by\n> default initially was exactly that, i.e. those opt into the feature\n> was used as guinea pigs to polish the feature. But we forgot to set\n> the graduation criteria and never said \"ok it is mature enough, so\n> let's turn it on for everybody\".\n>\n> Perhaps Git 3.0 boundary is a good occasion to do so?\n\nPerhaps, but I wonder if waiting until Git 3.0 is necessary. I use the\nrerere cache daily and have for years, so I consider this battle-tested\nat least in my own workflow.\n\nI'm not saying we should *necessarily* do this, but I wonder for\nargument's sake: what would prevent us from changing the default for\n2.52?\n\nThanks,\nTaylor\n"},{"id":"529333","messageId":"CALnO6CAjhgsGS-zoL_EQO0CXyg1gVH70TSqnbThNmJYarU71EQ@mail.gmail.com","threadId":"64364","inReplyTo":"ecf21e8d-acff-47fb-b972-59cd7b8f3146@app.fastmail.com","subject":"Re: [rfc] flip rerere.enabled default to be \"on\" at Git 3.0 boundary?","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-10-21T21:36:31Z","receivedAt":"2025-10-21T21:36:43Z","isPatch":false,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"On Tue, Oct 21, 2025 at 2:56 PM Kristoffer Haugsbakk\n wrote:\n>\n> On Tue, Oct 21, 2025, at 20:21, Junio C Hamano wrote:\n> > A good default matters, and people who find out how useful a rerere\n> > database is would say \"gee, that sounds great but why they do not\n> > enable it by default? It is too buggy and they wanted to reduce the\n> > number of support requests?\" Yes, the reason it is not enabled by\n> > default initially was exactly that, i.e. those opt into the feature\n> > was used as guinea pigs to polish the feature. But we forgot to set\n> > the graduation criteria and never said \"ok it is mature enough, so\n> > let's turn it on for everybody\".\n> >\n> > Perhaps Git 3.0 boundary is a good occasion to do so?\n>\n> This sounds nice.\n>\n> Sometimes I make bad resolutions and my cache gets in the way. But I\n> know it’s a directory or file somewhere that I can delete manually. So\n> that’s nice. And if I didn’t know I think I could have found it on\n> StackOverflow.\n>\n> I don’t think the “reused resolution” is super clear for things like\n> rebase and merge. I will get output like\n>\n> CONFLICT\n> CONFLICT\n> CONFLICT\n> Reused recorded resolution for ...\n> Reused recorded resolution for ...\n> Reused recorded resolution for ...\n> YOUR STUFF IS CONFLICTED\n> DO THIS AND THAT\n>\n> this is from memory :p\n>\n> And the “reused” messages are kind of “randomly” placed in the stderr\n> stream of consciousness. Could they be colored maybe?\n\nSeconding this: it's too easy to miss the rerere messages, which can\nmake other moments more confusing. (IIRC, git-status still says we\nneed to \"approve\" the resolution, but for folks not used to rerere it\nmight be obvious how to check the resolution? Idk, can't recall\noffhand.)\n"},{"id":"529335","messageId":"CALnO6CBJ7FQqa1JS5LoSqDa2KBHGZ=7KyUjQqNZWqHuq+nZOOA@mail.gmail.com","threadId":"64364","inReplyTo":"CALnO6CAjhgsGS-zoL_EQO0CXyg1gVH70TSqnbThNmJYarU71EQ@mail.gmail.com","subject":"Re: [rfc] flip rerere.enabled default to be \"on\" at Git 3.0 boundary?","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-10-21T21:37:07Z","receivedAt":"2025-10-21T21:37:19Z","isPatch":false,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"On Tue, Oct 21, 2025 at 5:36 PM D. Ben Knoble wrote:\n>\n> On Tue, Oct 21, 2025 at 2:56 PM Kristoffer Haugsbakk\n> wrote:\n> >\n> > On Tue, Oct 21, 2025, at 20:21, Junio C Hamano wrote:\n> > > A good default matters, and people who find out how useful a rerere\n> > > database is would say \"gee, that sounds great but why they do not\n> > > enable it by default? It is too buggy and they wanted to reduce the\n> > > number of support requests?\" Yes, the reason it is not enabled by\n> > > default initially was exactly that, i.e. those opt into the feature\n> > > was used as guinea pigs to polish the feature. But we forgot to set\n> > > the graduation criteria and never said \"ok it is mature enough, so\n> > > let's turn it on for everybody\".\n> > >\n> > > Perhaps Git 3.0 boundary is a good occasion to do so?\n> >\n> > This sounds nice.\n> >\n> > Sometimes I make bad resolutions and my cache gets in the way. But I\n> > know it’s a directory or file somewhere that I can delete manually. So\n> > that’s nice. And if I didn’t know I think I could have found it on\n> > StackOverflow.\n> >\n> > I don’t think the “reused resolution” is super clear for things like\n> > rebase and merge. I will get output like\n> >\n> > CONFLICT\n> > CONFLICT\n> > CONFLICT\n> > Reused recorded resolution for ...\n> > Reused recorded resolution for ...\n> > Reused recorded resolution for ...\n> > YOUR STUFF IS CONFLICTED\n> > DO THIS AND THAT\n> >\n> > this is from memory :p\n> >\n> > And the “reused” messages are kind of “randomly” placed in the stderr\n> > stream of consciousness. Could they be colored maybe?\n>\n> Seconding this: it's too easy to miss the rerere messages, which can\n> make other moments more confusing. (IIRC, git-status still says we\n> need to \"approve\" the resolution, but for folks not used to rerere it\n> might be obvious how to check the resolution? Idk, can't recall\n> offhand.)\n\nPremature send—the above said, I don't think it's anything against\ngraduating rerere to default. Just that there will be some more edges\nto polish, which is a good thing.\n\n-- \nD. Ben Knoble\n"},{"id":"529339","messageId":"xmqqsefbsxru.fsf@gitster.g","threadId":"64364","inReplyTo":"ecf21e8d-acff-47fb-b972-59cd7b8f3146@app.fastmail.com","subject":"Re: [rfc] flip rerere.enabled default to be \"on\" at Git 3.0 boundary?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-21T22:19:49Z","receivedAt":"2025-10-21T22:19:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Kristoffer Haugsbakk\" writes:\n\n> The biggest usability problem for me is when I have a cache, I want to\n> keep it, but I want to remove a few pathspecs. I’ve made some notes on\n> this to myself. Apparently I tried to `git rerere forget` on some paths\n> but I got not output. Then I did it again and it reused it. According\n> to my notes I had to get into that conflict resolution state and then\n> *forget*:\n>\n> (this is straight from my notes, I didn’t try this right now)\n>\n> 1. I did the wrong thing for `file`\n> 2. I reset the merge back\n> 3. I did the merge\n> 4. *While resolving conflicts*: `git rerere forget `\n> 5. `git merge --abort`\n> 6. Do merge again\n> 7. Now I can redo the merge conflict for `` while keeping the rest\n> of the resolutions\n>\n> I don’t know if all of that was necessary but that’s what I did to make\n> it work for me.\n\nThat is how I would do it. Of course if I know I can get to the\nright resolution without steps 5 and 6, then I'd just record the\nresolution after doing \"rerere forget\" at step 4.\n"},{"id":"529381","messageId":"bec27479-c53f-472c-87c7-374321108ad5@kdbg.org","threadId":"64364","inReplyTo":"ecf21e8d-acff-47fb-b972-59cd7b8f3146@app.fastmail.com","subject":"Re: [rfc] flip rerere.enabled default to be \"on\" at Git 3.0 boundary?","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2025-10-22T05:55:02Z","receivedAt":"2025-10-22T05:55:43Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 21.10.25 um 20:55 schrieb Kristoffer Haugsbakk:\n> On Tue, Oct 21, 2025, at 20:21, Junio C Hamano wrote:\n>> A good default matters, and people who find out how useful a rerere\n>> database is would say \"gee, that sounds great but why they do not\n>> enable it by default? It is too buggy and they wanted to reduce the\n>> number of support requests?\" Yes, the reason it is not enabled by\n>> default initially was exactly that, i.e. those opt into the feature\n>> was used as guinea pigs to polish the feature. But we forgot to set\n>> the graduation criteria and never said \"ok it is mature enough, so\n>> let's turn it on for everybody\".\n>>\n>> Perhaps Git 3.0 boundary is a good occasion to do so?\n> \n> This sounds nice.\n\nWhile I agree that the rerere cache is a very valuable tool to have, it\nhas the very sharp edge that a cached wrong resolution is extremely\ndifficult to get rid of.\n\nMerge conflicts and how to resolve them correctly is a skill that needs\nto be trained. Giving a novice who is still tipping their toes into the\nwaters of merge resolution the advice to \"just enable rerere\" exposes\nthem to a behavior whose results (the reuse of incorrect merge\nresolutions that they thought they had already corrected) are\ninexplicable without the help of an expert.\n\nI think I'm saying that I am mildly opposed to enable rerere by default\nas long as it has this sharp edge.\n\n> 1. I did the wrong thing for `file`\n> 2. I reset the merge back\n> 3. I did the merge\n> 4. *While resolving conflicts*: `git rerere forget `\n> 5. `git merge --abort`\n> 6. Do merge again\n> 7. Now I can redo the merge conflict for `` while keeping the rest\n> of the resolutions\n> \n> I don’t know if all of that was necessary but that’s what I did to make\n> it work for me.\n\nInstead of 5.+6., do `git checkout --merge `.\n\n> In short I guess I’m saying that git-rerere(1) isn’t that\n> straightforward if you want to figure out what is in the cache, if you\n> can delete things from it in your current state, things like that.\n\nCould rerere perhaps update the cache even after a resolution has been\nreused? Then a reused and then modified resolution would enter the\ncache, and the updated resolution would be reused if and when the merge\nis repeated.\n\n-- Hannes\n\n"},{"id":"529433","messageId":"80220653-7302-4E4D-99E9-1A8CB5B4F23D@gmail.com","threadId":"64364","inReplyTo":"bec27479-c53f-472c-87c7-374321108ad5@kdbg.org","subject":"Re: [rfc] flip rerere.enabled default to be \"on\" at Git 3.0 boundary?","fromName":"Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-10-22T17:45:01Z","receivedAt":"2025-10-22T17:45:13Z","isPatch":false,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"\n> Le 22 oct. 2025 à 01:55, Johannes Sixt a écrit :\n> \n> Am 21.10.25 um 20:55 schrieb Kristoffer Haugsbakk:\n>>> On Tue, Oct 21, 2025, at 20:21, Junio C Hamano wrote:\n>>> A good default matters, and people who find out how useful a rerere\n>>> database is would say \"gee, that sounds great but why they do not\n>>> enable it by default? It is too buggy and they wanted to reduce the\n>>> number of support requests?\" Yes, the reason it is not enabled by\n>>> default initially was exactly that, i.e. those opt into the feature\n>>> was used as guinea pigs to polish the feature. But we forgot to set\n>>> the graduation criteria and never said \"ok it is mature enough, so\n>>> let's turn it on for everybody\".\n>>> \n>>> Perhaps Git 3.0 boundary is a good occasion to do so?\n>> \n>> This sounds nice.\n> \n> While I agree that the rerere cache is a very valuable tool to have, it\n> has the very sharp edge that a cached wrong resolution is extremely\n> difficult to get rid of.\n> \n> Merge conflicts and how to resolve them correctly is a skill that needs\n> to be trained. Giving a novice who is still tipping their toes into the\n> waters of merge resolution the advice to \"just enable rerere\" exposes\n> them to a behavior whose results (the reuse of incorrect merge\n> resolutions that they thought they had already corrected) are\n> inexplicable without the help of an expert.\n> \n> I think I'm saying that I am mildly opposed to enable rerere by default\n> as long as it has this sharp edge.\n\nFair 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:\n- messaging is not clear\n- usage for dealing with incorrect caches needs improvement (should be useable without expert intervention)\n - as a first step, perhaps having rerere and status display more information about possible steps to take (review results, keep or discard) would help?"},{"id":"529440","messageId":"xmqqsefaydfg.fsf@gitster.g","threadId":"64364","inReplyTo":"80220653-7302-4E4D-99E9-1A8CB5B4F23D@gmail.com","subject":"Re: [rfc] flip rerere.enabled default to be \"on\" at Git 3.0 boundary?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-22T18:54:59Z","receivedAt":"2025-10-22T18:55:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ben Knoble writes:\n\n>> I think I'm saying that I am mildly opposed to enable rerere by default\n>> as long as it has this sharp edge.\n>\n> 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:\n> - messaging is not clear\n> - usage for dealing with incorrect caches needs improvement (should be useable without expert intervention)\n> - as a first step, perhaps having rerere and status display more information about possible steps to take (review results, keep or discard) would help?\n\n- delete/modify conflicts are not recorded and replayed due to\n safety concerns [*], but in practice, most of the time it seems\n that the user wishes to re-resolve such a conflict to 'delete' the\n path.\n\n[Footnote]\n\n * The modification that is safe to discard when resolving the\n conflict to remove the path today may not apply if the\n modification to the path that is deleted is different and may\n require a different resolution other than discarding it.\n"},{"id":"529518","messageId":"CALnO6CB3EZkAyc_fWdU+P_MLcipZ4T90RSk0+46Fc20OmWEpmQ@mail.gmail.com","threadId":"64364","inReplyTo":"xmqqsefaydfg.fsf@gitster.g","subject":"Re: [rfc] flip rerere.enabled default to be \"on\" at Git 3.0 boundary?","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-10-23T19:19:57Z","receivedAt":"2025-10-23T19:20:10Z","isPatch":false,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"I think I'm confused, which is probably on my end, but let me try to\nclear up what I wrote, at least.\n\nOn Wed, Oct 22, 2025 at 2:55 PM Junio C Hamano wrote:\n>\n> Ben Knoble writes:\n>\n> >> I think I'm saying that I am mildly opposed to enable rerere by default\n> >> as long as it has this sharp edge.\n> >\n> > 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:\n> > - messaging is not clear\n> > - usage for dealing with incorrect caches needs improvement (should be useable without expert intervention)\n> > - as a first step, perhaps having rerere and status display more information about possible steps to take (review results, keep or discard) would help?\n\n[On the chance that the reply was due to this wording]\n\nHere, \"keep or discard\" were meant as possible actions to take on the\nrerere resolution. Something like\n\ngit status\n…\nfile (recorded resolution reused)\n…\nhint: To review the reused resolutions, run X\nhint: To discard them, run Y\nhint: Concluding the merge without discarding them will keep them.\n\nor some such.\n\n> - delete/modify conflicts are not recorded and replayed due to\n> safety concerns [*], but in practice, most of the time it seems\n> that the user wishes to re-resolve such a conflict to 'delete' the\n> path.\n>\n> [Footnote]\n>\n> * The modification that is safe to discard when resolving the\n> conflict to remove the path today may not apply if the\n> modification to the path that is deleted is different and may\n> require a different resolution other than discarding it.\n\nWas this intended as \"another todo list item to work on\"? If so, I'm\nafraid I'm having trouble decoding what the issue that needs fixed is.\nMy nth re-read suggests that the sharp edge here is \"delete/modify\nconflicts often need re-resolution favoring delete\" and that doing so\nis not easy today?\n\n-- \nD. Ben Knoble\n"},{"id":"529523","messageId":"xmqqtszptnco.fsf@gitster.g","threadId":"64364","inReplyTo":"CALnO6CB3EZkAyc_fWdU+P_MLcipZ4T90RSk0+46Fc20OmWEpmQ@mail.gmail.com","subject":"Re: [rfc] flip rerere.enabled default to be \"on\" at Git 3.0 boundary?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-23T19:44:07Z","receivedAt":"2025-10-23T19:44:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"D. Ben Knoble\" writes:\n\n> Was this intended as \"another todo list item to work on\"? If so, I'm\n> afraid I'm having trouble decoding what the issue that needs fixed is.\n> My nth re-read suggests that the sharp edge here is \"delete/modify\n> conflicts often need re-resolution favoring delete\" and that doing so\n> is not easy today?\n\nIt meant to add to the list another sharp-edge, which is that\n'rerere' does not even attempt to help you deal with delete-modify\nconflicts at all. Either it needs to be communicated better that\nthe users are on their own with delete-modify conflicts, or a good\nsupport needs to be designed and documented.\n\n"},{"id":"529535","messageId":"EFDCC7CA-EA06-4149-AD2F-5CE4DF336E1E@gmail.com","threadId":"64364","inReplyTo":"xmqqtszptnco.fsf@gitster.g","subject":"Re: [rfc] flip rerere.enabled default to be \"on\" at Git 3.0 boundary?","fromName":"Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-10-23T22:03:11Z","receivedAt":"2025-10-23T22:03:24Z","isPatch":false,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"\n\n> Le 23 oct. 2025 à 15:44, Junio C Hamano a écrit :\n> \n> \"D. Ben Knoble\" writes:\n> \n>> Was this intended as \"another todo list item to work on\"? If so, I'm\n>> afraid I'm having trouble decoding what the issue that needs fixed is.\n>> My nth re-read suggests that the sharp edge here is \"delete/modify\n>> conflicts often need re-resolution favoring delete\" and that doing so\n>> is not easy today?\n> \n> It meant to add to the list another sharp-edge, which is that\n> 'rerere' does not even attempt to help you deal with delete-modify\n> conflicts at all. Either it needs to be communicated better that\n> the users are on their own with delete-modify conflicts, or a good\n> support needs to be designed and documented.\n\nThanks!\n"}]}