Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: tilak-raaz <raaztilak07@gmail.com>
Cc: git@vger.kernel.org,  wy@wyuan.org,  ben.knoble@gmail.com
Subject: Re: [PATCH v4] submodule: warn on valueless active config
Date: Mon, 17 Aug 2026 10:43:34 -0700	[thread overview]
Message-ID: <xmqqjypo4p89.fsf@gitster.g> (raw)
In-Reply-To: <20260815071829.22190-1-raaztilak07@gmail.com> (tilak-raaz's message of "Sat, 15 Aug 2026 12:48:29 +0530")

tilak-raaz <raaztilak07@gmail.com> writes:

> The config parser throws a hard error if 'submodule.active'
> is provided without a value, causing commands to abort.

Why is it a bad thing in the first place?

    $ echo "[submodule] config" >>.git/config
    $ git submodule
    error: missing value for 'submodule.active'

Is this error message not sufficient for users to go on finding
where their configuration file is broken and fixing it?

>  	/* submodule.active is set */
> -	if (!repo_config_get_string_multi(repo, "submodule.active", &sl)) {
> +	if (!repo_config_get_value_multi(repo, "submodule.active", &sl)) {
>  		struct pathspec ps;
>  		struct strvec args = STRVEC_INIT;
>  		const struct string_list_item *item;
>  
>  		for_each_string_list_item(item, sl) {
> +			 if (!item->string) {
> +				config_error_nonbool("submodule.active");
> +				continue;
> +			}

Warning and continuing as if no misconfigured variable existed?  I
do not think it is an improvement.  Without stopping the process,
the early error messages will just scroll away without giving the
chance for the user to notice.

tilak-raaz <raaztilak07@gmail.com> writes:

> The config parser throws a hard error if 'submodule.active'
> is provided without a value, causing commands to abort.
>
> Swap repo_config_get_string_multi() to repo_config_get_value_multi()
> to parse valueless true safely. Use the standard config_error_nonbool()
> helper to emit a warning to the user rather than crashing.
>
> This resolves a NEEDSWORK comment in submodule.c.

NEEDSWORK is different from TODO in that whoever addresses it must
think if what the comment suggests to do is sensible in the first
place.  I do not think it is in this case.  IOW, unlike TODO, there
are two valid ways to resolve NEEDSWORK, (1) analyze the issue and
validate that the suggested change is sensible, and then adjust the
code to match, or (2) analyze the issue and determine that the
suggested change is not a good idea, and then remove (or update) the
comment.

> Signed-off-by: tilak-raaz <raaztilak07@gmail.com>

Documentation/SubmittingPatches::[real-name]???


> (Apologies for the noisy v3; I botched my --amend and accidentally left the commit message in the past tense. This v4 corrects the commit message.)
>
> Regarding causing the command to fail on a malformed config: I investigated returning an error code here, but is_tree_submodule_active() is evaluated as a boolean predicate by its callers (for example, if (!is_tree_submodule_active(...))). Since -1 is truthy in C, returning -1 would cause callers to treat the broken submodule as active.
>
> To avoid changing the existing caller semantics or introducing process termination from this helper, I kept the continue behavior so the malformed entry is skipped after being reported with config_error_nonbool(), while valid entries continue to be processed.

All overly long lines.  Wrap them ~70 columns.

Thanks.

      reply	other threads:[~2026-08-17 17:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <MESSAGE_ID_FROM_JUNIOS_LAST_EMAIL>
2026-08-15  7:00 ` [PATCH v3] submodule: warn on valueless active config tilak-raaz
2026-08-15  7:18 ` [PATCH v4] " tilak-raaz
2026-08-17 17:43   ` Junio C Hamano [this message]

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=xmqqjypo4p89.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=ben.knoble@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=raaztilak07@gmail.com \
    --cc=wy@wyuan.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox