From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: Justin Tobler <jltobler@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH v3 3/4] fetch-pack: split out fsck config parsing
Date: Wed, 04 Dec 2024 11:39:04 +0900 [thread overview]
Message-ID: <xmqq34j45fzr.fsf@gitster.g> (raw)
In-Reply-To: <xmqqy10w9x0m.fsf@gitster.g> (Junio C. Hamano's message of "Wed, 04 Dec 2024 08:17:45 +0900")
Junio C Hamano <gitster@pobox.com> writes:
> Patrick Steinhardt <ps@pks.im> writes:
>
>> I think the current version of this patch series is fine as-is then. It
>> might be a good idea to adapt this in a follow-up series, unless there
>> is a good reason not to.
>
> Sounds good. We may want to tighten the rules a bit to reject
> obvious misconfigurations, but that is outside the scope of this
> topic.
This reminds me of a slightly related tangent.
There are pathname-valued ones that we added deliberately as an
optional configuration variable, IIRC, and fsck.skiplist may be one
of them. In other words, they mean "In a repository that I want the
configuration to affect, I'll have the configuration file at this
path, but it is merely optional. If it is missing, pretend as if
the configuration variable does not even exist".
In retrospect, it was a mistake to define that this variable is
required and triggers an error when misconfigured, and that variable
is optional and triggers only a warning when misconfigured. That is
one more thing for the user to remember and does not scale.
We probably should have done something like
- the value given to all pathname valued configuration variables
and command name options MUST correctly name a path that the
command can read, and a misconfigured configuration variable or
an invalid command line option should trigger an error when the
command needs to access it.
- the value (not the variable) can say "I am optional--if the path
does not appear on this system, or if it is unreadable, pretend
as if this configuration variable or the command line option were
not given".
The "when the command needs to" part is important. Ideally, "git
log" should not fail when core.hookspath is misconfigured, because
it does not trigger any hook, but it currently dies while parsing
the configuration files in git_default_config():
$ git -c core.hookspath log
error: missing value for 'core.hookspath'
fatal: unable to parse 'core.hookspath' from command-line config.
which we may want to fix. Unsurprisingly there are other variables
that do behave correctly, like
$ git -c core.pager --no-pager log -20 >/dev/null
$ git -c core.pager log -20 >/dev/null
error: missing value for 'core.pager'
fatal: unable to parse command-line config
where a misconfigured core.pager does not cause any trouble when the
pager is not in use.
Any of the above are not within the scope of this topic, obviously.
cf. <20241014204427.1712182-1-gitster@pobox.com>
next prev parent reply other threads:[~2024-12-04 2:39 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-21 20:41 [PATCH 0/5] propagate fsck message severity for bundle fetch Justin Tobler
2024-11-21 20:41 ` [PATCH 1/5] bundle: add bundle verification options type Justin Tobler
2024-11-22 1:21 ` Junio C Hamano
2024-11-22 15:22 ` Justin Tobler
2024-11-26 9:08 ` Patrick Steinhardt
2024-11-26 15:59 ` Justin Tobler
2024-11-21 20:41 ` [PATCH 2/5] bundle: support fsck message configuration Justin Tobler
2024-11-22 1:30 ` Junio C Hamano
2024-11-22 15:44 ` Justin Tobler
2024-11-25 1:33 ` Junio C Hamano
2024-11-21 20:41 ` [PATCH 3/5] fetch-pack: introduce `fetch_pack_options` Justin Tobler
2024-11-22 1:46 ` Junio C Hamano
2024-11-22 3:46 ` Junio C Hamano
2024-11-22 17:31 ` Justin Tobler
2024-11-21 20:41 ` [PATCH 4/5] fetch-pack: expose `fetch_pack_config_cb()` Justin Tobler
2024-11-22 1:57 ` Junio C Hamano
2024-11-22 17:41 ` Justin Tobler
2024-11-22 16:45 ` shejialuo
2024-11-27 1:21 ` Justin Tobler
2024-11-21 20:41 ` [PATCH 5/5] transport: propagate fsck configuration during bundle fetch Justin Tobler
2024-11-22 1:59 ` Junio C Hamano
2024-11-27 0:57 ` [PATCH v2 0/4] propagate fsck message severity for " Justin Tobler
2024-11-27 0:57 ` [PATCH v2 1/4] bundle: add bundle verification options type Justin Tobler
2024-11-27 0:57 ` [PATCH v2 2/4] bundle: support fsck message configuration Justin Tobler
2024-11-27 5:44 ` Patrick Steinhardt
2024-11-27 0:57 ` [PATCH v2 3/4] fetch-pack: split out fsck config parsing Justin Tobler
2024-11-27 5:44 ` Patrick Steinhardt
2024-11-27 17:37 ` Justin Tobler
2024-11-27 0:57 ` [PATCH v2 4/4] transport: propagate fsck configuration during bundle fetch Justin Tobler
2024-11-27 1:39 ` Junio C Hamano
2024-11-27 23:33 ` [PATCH v3 0/4] propagate fsck message severity for " Justin Tobler
2024-11-27 23:33 ` [PATCH v3 1/4] bundle: add bundle verification options type Justin Tobler
2024-11-27 23:33 ` [PATCH v3 2/4] bundle: support fsck message configuration Justin Tobler
2024-11-27 23:33 ` [PATCH v3 3/4] fetch-pack: split out fsck config parsing Justin Tobler
2024-11-28 3:25 ` Junio C Hamano
2024-12-03 9:34 ` Patrick Steinhardt
2024-12-03 14:23 ` Justin Tobler
2024-12-03 14:28 ` Patrick Steinhardt
2024-12-03 23:17 ` Junio C Hamano
2024-12-04 2:39 ` Junio C Hamano [this message]
2024-11-27 23:33 ` [PATCH v3 4/4] transport: propagate fsck configuration during bundle fetch Justin Tobler
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=xmqq34j45fzr.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jltobler@gmail.com \
--cc=ps@pks.im \
/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).