git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org,  johannes.schindelin@gmx.de,
	 Patrick Steinhardt <ps@pks.im>,
	 Derrick Stolee <stolee@gmail.com>
Subject: Re: [PATCH v3 4/4] scalar reconfigure: add --maintenance=<mode> option
Date: Wed, 07 May 2025 14:46:55 -0700	[thread overview]
Message-ID: <xmqqcyckayb4.fsf@gitster.g> (raw)
In-Reply-To: <684f04aaf7e87f22ab0b00a4fd42d2943304ef04.1746582637.git.gitgitgadget@gmail.com> (Derrick Stolee via GitGitGadget's message of "Wed, 07 May 2025 01:50:37 +0000")

"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:

> Add a new --maintenance=<mode> option to 'scalar reconfigure' that
> provides options for enabling (default), disabling, or leaving
> background maintenance config as-is.

Hmph, this is a bit unexpected.

> +--maintenance=<mode>::
> +	By default, Scalar configures the enlistment to use Git's
> +	background maintenance feature; this is the same as using the
> +	`--maintenance=enable` value for this option. Use the
> +	`--maintenance=disable` to remove each considered enlistment
> +	from background maintenance. Use `--maitnenance=keep' to leave
> +	the background maintenance configuration untouched for These
> +	repositories.

If I understand it correctly, here is the only place that the users
can learn what the valid choices are, and it is not even an
enumeration.  They are forced to read the entire paragraph to learn
what the choices are.

> +		OPT_STRING(0, "maintenance", &maintenance_str,
> +			 N_("<mode>"),
> +			 N_("signal how to adjust background maintenance")),

And there is no hint what are the right <mode> strings are.

>  	const char * const usage[] = {
> -		N_("scalar reconfigure [--all | <enlistment>]"),
> +		N_("scalar reconfigure [--maintenance=<mode>] [--all | <enlistment>]"),
>  		NULL
>  	};

So "scalar reconfigure -h" would not tell readers what the right
choices are, either.

> +	if (maintenance_str) {
> +		if (!strcmp(maintenance_str, "enable"))
> +			maintenance = 1;
> +		else if (!strcmp(maintenance_str, "disable"))
> +			maintenance = 0;
> +		else if (!strcmp(maintenance_str, "keep"))
> +			maintenance = -1;
> +		else
> +			die(_("unknown mode for --maintenance option: %s"),
> +			    maintenance_str);

Those who say "scalar reconfigure --maintenance=yes" gets this
message that tells 'yes' is not a known mode, without saying that
they meant 'enable'.  

The --opt=<mode> interface is good when we expect the vocabulary for
<mode> to grow, but I am not sure if it is warranted in this case.
Is there a strong reason why 'reconfigure' MUST enable the
maintenance by default, even if it were originally disabled in the
enlistment?  If there isn't, initializing maintenance to -1 and
setting it with OPT_BOOL() would make the UI consistent with the
register and clone subcommands, and also we can lose the above block
to parse out a string.  Also the code below ...


> @@ -758,7 +776,8 @@ static int cmd_reconfigure(int argc, const char **argv)
>  		the_repository = old_repo;
>  		repo_clear(&r);
>  
> -		if (toggle_maintenance(1) >= 0)
> +		if (maintenance >= 0 &&
> +		    toggle_maintenance(maintenance) >= 0)
>  			succeeded = 1;

... which does make perfect sense, would still be applicable.

I dunno.  I just feel that 3-way "mode" interface is too much hassle
to get right (e.g., give hints to guide the users who forgot what
modes are available and how they are spelled) for this code path.

Anyway, will replace the previous round with this one.

Thanks.



  reply	other threads:[~2025-05-07 21:46 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-30 10:24 [PATCH 0/2] scalar: add --no-maintenance option Derrick Stolee via GitGitGadget
2025-04-30 10:24 ` [PATCH 1/2] scalar register: " Derrick Stolee via GitGitGadget
2025-05-02  9:15   ` Patrick Steinhardt
2025-05-02 15:01     ` Derrick Stolee
2025-04-30 10:24 ` [PATCH 2/2] scalar clone: " Derrick Stolee via GitGitGadget
2025-04-30 20:28 ` [PATCH 0/2] scalar: " Junio C Hamano
2025-05-01 13:21   ` Derrick Stolee
2025-05-01 16:38     ` Junio C Hamano
2025-05-01 18:20       ` Junio C Hamano
2025-05-05 15:27 ` [PATCH v2 0/4] " Derrick Stolee via GitGitGadget
2025-05-05 15:27   ` [PATCH v2 1/4] scalar: customize register_dir()'s behavior Derrick Stolee via GitGitGadget
2025-05-05 15:27   ` [PATCH v2 2/4] scalar register: add --no-maintenance option Derrick Stolee via GitGitGadget
2025-05-05 15:27   ` [PATCH v2 3/4] scalar clone: " Derrick Stolee via GitGitGadget
2025-05-05 15:27   ` [PATCH v2 4/4] scalar reconfigure: " Derrick Stolee via GitGitGadget
2025-05-05 21:47     ` Junio C Hamano
2025-05-06 18:00       ` Derrick Stolee
2025-05-06 22:16         ` Junio C Hamano
2025-05-07  1:50   ` [PATCH v3 0/4] scalar: " Derrick Stolee via GitGitGadget
2025-05-07  1:50     ` [PATCH v3 1/4] scalar: customize register_dir()'s behavior Derrick Stolee via GitGitGadget
2025-05-07  1:50     ` [PATCH v3 2/4] scalar register: add --no-maintenance option Derrick Stolee via GitGitGadget
2025-05-07  1:50     ` [PATCH v3 3/4] scalar clone: " Derrick Stolee via GitGitGadget
2025-05-07  1:50     ` [PATCH v3 4/4] scalar reconfigure: add --maintenance=<mode> option Derrick Stolee via GitGitGadget
2025-05-07 21:46       ` Junio C Hamano [this message]
2025-05-12 14:34         ` Derrick Stolee
2025-05-12 17:44           ` Junio C Hamano
2025-05-12 18:02             ` Derrick Stolee
2025-05-14 12:28               ` Junio C Hamano
2025-05-14 13:52     ` [PATCH 5/4] scalar reconfigure: improve --maintenance docs Derrick Stolee
2025-05-14 22:16       ` Junio C Hamano
2025-05-16 16:36         ` Derrick Stolee

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=xmqqcyckayb4.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=johannes.schindelin@gmx.de \
    --cc=ps@pks.im \
    --cc=stolee@gmail.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).