All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] rerere: enable by default
Date: Mon, 07 Jun 2021 20:05:09 +0900	[thread overview]
Message-ID: <xmqqpmwyue8q.fsf@gitster.g> (raw)
In-Reply-To: <877dj654or.fsf@evledraar.gmail.com> (=?utf-8?B?IsOGdmFyIEFy?= =?utf-8?B?bmZqw7Zyw7A=?= Bjarmason"'s message of "Mon, 07 Jun 2021 11:50:35 +0200")

Ævar Arnfjörð Bjarmason <avarab@gmail.com> 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.

  reply	other threads:[~2021-06-07 11:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-06 12:30 [PATCH] rerere: enable by default Junio C Hamano
2021-06-07  0:56 ` brian m. carlson
2021-06-07  9:51   ` Junio C Hamano
2021-06-07  9:50 ` Ævar Arnfjörð Bjarmason
2021-06-07 11:05   ` Junio C Hamano [this message]
2021-06-07 12:56     ` Ævar Arnfjörð Bjarmason
2021-06-07 10:34 ` Andrei Rybak
2021-06-07 16:41 ` Felipe Contreras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqpmwyue8q.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.