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 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.