Subject: Re: [PATCH] rerere: enable by default

From: Junio C Hamano <[email-masked]>
Date: Mon, 07 Jun 2021 20:05:09 +0900

Ævar Arnfjörð Bjarmason <[email-masked]> 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.