Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > On Sun, Jun 06 2021, Junio C Hamano wrote: > >> By default, the rerere machinery has been disabled since a bug in >> the machinery could screw up the end user's data at the most >> stressful time during the end user's workday (i.e. during conflict >> resolution). > > What was that bug & in what commit was it fixed? Makes sense to note > that here. There is no such bug ;-). Writing buggy code, not thinking about it carefully enough and jumping up and down yelling this shiny new toy must be merged down immediately is something we see on this list from others, but it is the total opposite of how I operate. I just am extra cautious and even after I am reasonably sure the code would not break, I prefer to have volunteers to opt into testing. > @@ -130,7 +129,6 @@ test_expect_success 'unmerge with plumbing' ' > test_expect_success 'rerere and rerere forget' ' > # from here on, use rerere. > git config rerere.enabled true && > - mkdir .git/rr-cache && > prime_resolve_undo && > echo record the resolution && > git rerere && > > So the only impact of that rerere.enabled=false early is to make sure > we're not creating the .git/rr-cache. Not really. Unresolve is about recording the initial conflict in the index, so it is far easier to see its effect if you do not enable rerere, when you are manually debugging these earlier tests. And later test do check how it works with rerere enabled, but the way the original sequence of tests enable it is with the "mkdir". I.e. "if rerere.enabled is not set either way, presence of the directory means it is already enabled". The new test sequence uses the configuration variable explicitly, because in the new world order, the presence of the directory does not mean a thing.
