From: Patrick Steinhardt <ps@pks.im>
To: kristofferhaugsbakk@fastmail.com
Cc: git@vger.kernel.org, Kristoffer Haugsbakk <code@khaugsbakk.name>
Subject: Re: [PATCH] t1400: fix --no-create-reflog test and description
Date: Mon, 21 Oct 2024 14:08:44 +0200 [thread overview]
Message-ID: <ZxZETN7WjbNiSRyF@pks.im> (raw)
In-Reply-To: <ab7d4c8d89c075de05bf04f1f9dc195145455964.1729439476.git.code@khaugsbakk.name>
On Sun, Oct 20, 2024 at 06:12:03PM +0200, kristofferhaugsbakk@fastmail.com wrote:
> From: Kristoffer Haugsbakk <code@khaugsbakk.name>
>
> This test has had the wrong title since it was created.[1] Use `always`
> like the description says and negate the expected outcome.
>
> The test works since `core.logAllRefUpdates` set to `true` does not
> create a reflog for that ref namespace. So the test is testing the
> config variable, not the option.
>
> The test itself is fine and does not hide a bug: `--no-create-reflog` is
> not supposed to override `core.logAllRefUpdates`.
That's actually surprising to me, as command line options tend to
override configuration.
> † 1: 341fb286212 (refs: add option core.logAllRefUpdates = always,
> 2017-01-27)
>
> Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
> ---
>
> Notes (series):
> From the commit message:
>
> “ The test itself is fine and does not hide a bug:
> `--no-create-reflog` is not supposed to override
>
> A source for that: roundabout through git-branch(1):
>
> “ The negated form --no-create-reflog only overrides an earlier
> --create-reflog, but currently does not negate the setting of
> core.logAllRefUpdates.
Hm. The "currently" reads as if this was a known shortcoming rather than
by design.
> I *suppose* that the same applies to update-ref since (I suppose) they
> use the same underlying machinery.
>
> See also git-tag(1) which says the same thing.
>
> update-ref should document the same thing, then. I have that marked as
> a todo item. The changes there are a bit too involved to implicate in
> this submission.
So I'm quite torn here. It's documented, even though the documentation
doesn't exactly feel like this was designed, but rather like it was a
side effect. The test also contradicts the documentation, even though it
only worked by chance. And as mentioned above, everywhere else we
typically have a design where the command line option overrides the
config.
Overall I'm rather leaning into the direction of making this work
properly. But that would of course be a backwards-incompatible change.
Patrick
next prev parent reply other threads:[~2024-10-21 12:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-20 16:12 [PATCH] t1400: fix --no-create-reflog test and description kristofferhaugsbakk
2024-10-21 12:08 ` Patrick Steinhardt [this message]
2024-10-21 16:48 ` Kristoffer Haugsbakk
2024-10-21 19:02 ` Taylor Blau
2024-10-21 21:02 ` Kristoffer Haugsbakk
2024-10-21 21:10 ` Taylor Blau
2024-11-07 12:11 ` Kristoffer Haugsbakk
2024-11-08 3:13 ` 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=ZxZETN7WjbNiSRyF@pks.im \
--to=ps@pks.im \
--cc=code@khaugsbakk.name \
--cc=git@vger.kernel.org \
--cc=kristofferhaugsbakk@fastmail.com \
/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).