Re: [PATCH v2 1/2] maintenance: add 'unregister --force'

From: SZEDER Gábor <szeder.dev@gmail.com>
Date: Sep 23, 2022, 13:08 UTC
Message-ID: <20220923130832.GA1761@szeder.dev>
In-Reply-To: <69c74f52eefd906c38494759a02e137e4d7c01d8.1663853837.git.gitgitgadget@gmail.com>

On Thu, Sep 22, 2022 at 01:37:16PM +0000, Derrick Stolee via GitGitGadget wrote:

Show 6 quoted lines

>  static int maintenance_unregister(int argc, const char **argv, const char *prefix)
>  {
> +	int force = 0;
>  	struct option options[] = {
> +		OPT_BOOL(0, "force", &force,
> +			 N_("return success even if repository was not registered")),

This could be shortened a bit by using OPT__FORCE() instead of OPT_BOOL(). OTOH, please make it a bit longer, and declare the option with the PARSE_OPT_NOCOMPLETE flag to hide it from completion: '--force' is usually used to enable something potentially dangerous, and therefore should be used with care, so our completion script in general doesn't offer it, giving the users more opportunity to think things through while typing it out. Though, arguably in this particular case it seems there is not much danger to be afraid of.

Show 20 quoted lines

> @@ -1538,11 +1545,23 @@ static int maintenance_unregister(int argc, const char **argv, const char *prefi
>  		usage_with_options(builtin_maintenance_unregister_usage,
>  				   options);
>  
> -	config_unset.git_cmd = 1;
> -	strvec_pushl(&config_unset.args, "config", "--global", "--unset",
> -		     "--fixed-value", "maintenance.repo", maintpath, NULL);
> +	for_each_string_list_item(item, list) {
> +		if (!strcmp(maintpath, item->string)) {
> +			found = 1;
> +			break;
> +		}
> +	}
> +
> +	if (found) {
> +		config_unset.git_cmd = 1;
> +		strvec_pushl(&config_unset.args, "config", "--global", "--unset",
> +			     "--fixed-value", key, maintpath, NULL);
> +
> +		rc = run_command(&config_unset);

It seems a bit heavy-handed to fork() an extra git process just to unset a config variable. Wouldn't a properly parametrized git_config_set_multivar_in_file_gently() call be sufficient? Though TBH I don't offhand know what those parameters should be, in particular whether there is a convenient way to find out the path of the global config file in order to pass it to this function.

(Not an issue with this patch, as the context shows that this has been done with the extra process before; it just caught my eye.)