From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Cc: Matthias Beyer <mail@beyermatthias.de>,
Konstantin Khomoutov <kostix@bswap.ru>,
Phillip Wood <phillip.wood@dunelm.org.uk>
Subject: Re: [PATCH v2] Add note that conflict resolution is still performed
Date: Fri, 15 Jul 2022 14:50:12 -0700 [thread overview]
Message-ID: <xmqqv8ryxcyz.fsf@gitster.g> (raw)
In-Reply-To: <xmqq35f2ysd9.fsf@gitster.g> (Junio C. Hamano's message of "Fri, 15 Jul 2022 14:32:18 -0700")
Junio C Hamano <gitster@pobox.com> writes:
> A tangent that may be worth thinking about, that does not have to be
> part of this topic (as it probably will involve code change).
>
> It makes sense that "--no-rerere-autoupdate" does not disable the
> "rerere" mechanism (when it is enabled, of course), because it makes
> sense to reuse recorded resolution without updating the index with
> the result.
>
> However, it may make sense to have "--rerere-autoupdate" option to
> enable the "rerere" mechanism when it is disabled, because with
> "rerere" disabled, there is nothing to auto-update.
I think the damage to the code to implement the above may not be too
bad. Here is an illustration (not even compile tested) of the idea:
- Earlier, after reading the config, we asked is_rerere_enabled()
and let its logic decide if rerere is to be used, giving no
influence to the incoming "flags" parameter. Then the value of
rerere_autoupdate read from the config is further adjusted by the
value in "flags" parameter that relays --[no-]rerere-autoupdate
from the command line.
- Instead, after reading the config, we can tweak it with the
"flags", and flip rerere_enabled to true if autoupdate is
enabled, before making a call to is_rerere_enabled().
I do not think we have a test that insists that rerere does not kick
in in a repository where rerere is disabled and the command line
asks for "--rerere-autoupdate", so I suspect that with this patch, I
would not be surprised if no test breaks. If we think this takes us
in a good direction, we should add a few tests to make sure at least
the following two:
- In a repository with rerere disabled, running a command with the
"--rerere-autoupdate" option will enable rerere for that single
invocation of the command.
- In a repository with rerere enabled, running a command with the
"--no-rerere-autoupdate" option does not disable rerere for that
single invocation of the command.
---
rerere.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git c/rerere.c w/rerere.c
index 876ab435da..16d3e865e6 100644
--- c/rerere.c
+++ w/rerere.c
@@ -872,11 +872,13 @@ int setup_rerere(struct repository *r, struct string_list *merge_rr, int flags)
int fd;
git_rerere_config();
+ if (flags & (RERERE_AUTOUPDATE|RERERE_NOAUTOUPDATE))
+ rerere_autoupdate = !!(flags & RERERE_AUTOUPDATE);
+ if (rerere_autoupdate)
+ rerere_enabled = 1;
if (!is_rerere_enabled())
return -1;
- if (flags & (RERERE_AUTOUPDATE|RERERE_NOAUTOUPDATE))
- rerere_autoupdate = !!(flags & RERERE_AUTOUPDATE);
if (flags & RERERE_READONLY)
fd = 0;
else
next prev parent reply other threads:[~2022-07-15 21:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <xmqq35f6fe0j.fsf@gitster.g>
2022-07-15 9:25 ` [PATCH v2] Add note that conflict resolution is still performed Matthias Beyer
2022-07-15 21:32 ` Junio C Hamano
2022-07-15 21:50 ` Junio C Hamano [this message]
2022-08-03 20:59 ` [PATCH] doc: clarify rerere-autoupdate Junio C Hamano
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=xmqqv8ryxcyz.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=kostix@bswap.ru \
--cc=mail@beyermatthias.de \
--cc=phillip.wood@dunelm.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).