git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Atharva Raykar <raykar.ath@gmail.com>
Cc: git@vger.kernel.org, "Emily Shaffer" <emilyshaffer@google.com>,
	"Jonathan Nieder" <jrnieder@gmail.com>,
	"Junio C Hamano" <gitster@pobox.com>,
	"Christian Couder" <christian.couder@gmail.com>,
	"Shourya Shukla" <periperidip@gmail.com>,
	"Kaartic Sivaraam" <kaartic.sivaraam@gmail.com>,
	"Eric Sunshine" <sunshine@sunshineco.com>,
	"Prathamesh Chavan" <pc44800@gmail.com>,
	"Đoàn Trần Công Danh" <congdanhqx@gmail.com>,
	"Rafael Silva" <rafaeloliveira.cs@gmail.com>
Subject: Re: [GSoC] [PATCH] submodule--helper: introduce add-config subcommand
Date: Thu, 22 Jul 2021 13:50:14 +0200	[thread overview]
Message-ID: <87sg06tvab.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <20210722112143.97944-1-raykar.ath@gmail.com>


On Thu, Jul 22 2021, Atharva Raykar wrote:

> +static void config_submodule_in_gitmodules(const char *name, const char *var, const char *value)
> +{
> +	char *key;
> +
> +	if (!is_writing_gitmodules_ok())
> +		die(_("please make sure that the .gitmodules file is in the working tree"));
> +
> +	key = xstrfmt("submodule.%s.%s", name, var);
> +	config_set_in_gitmodules_file_gently(key, value);
> +	free(key);
> +}

Just a small point not per-se to do with this patch, but aren't all
callers of config_set_in_gitmodules_file_gently() wanting to prefix
thigs with "submodule."? Looks like its API could be simplified a bit
with that xstrfmt() and free() inside that function.

> +static void configure_added_submodule(struct add_data *add_data)
> +{
> +	char *key, *submod_pathspec = NULL;
> +	struct child_process add_submod = CHILD_PROCESS_INIT;
> +	struct child_process add_gitmodules = CHILD_PROCESS_INIT;
> +	int pathspec_key_exists, activate = 0;

Usual style is to have different variables on different lines, unless
they're closely related (like "int i, j"), so "char *key;\n char
*submod[...]" in this case.

> +
> +	key = xstrfmt("submodule.%s.url", add_data->sm_name);
> +	git_config_set_gently(key, add_data->realrepo);
> +	free(key);
> +
> +	add_submod.git_cmd = 1;
> +	strvec_pushl(&add_submod.args, "add",
> +		     "--no-warn-embedded-repo", NULL);
> +	if (add_data->force)
> +		strvec_push(&add_submod.args, "--force");
> +	strvec_pushl(&add_submod.args, "--", add_data->sm_path, NULL);
> +
> +	if (run_command(&add_submod))
> +		die(_("Failed to add submodule '%s'"), add_data->sm_path);
> +
> +	config_submodule_in_gitmodules(add_data->sm_name, "path", add_data->sm_path);
> +	config_submodule_in_gitmodules(add_data->sm_name, "url", add_data->repo);
> +	if (add_data->branch)
> +		config_submodule_in_gitmodules(add_data->sm_name,
> +					       "branch", add_data->branch);
> +
> +	add_gitmodules.git_cmd = 1;
> +	strvec_pushl(&add_gitmodules.args,
> +		     "add", "--force", "--", ".gitmodules", NULL);
> +
> +	if (run_command(&add_gitmodules))
> +		die(_("Failed to register submodule '%s'"), add_data->sm_path);

Looks good at a glance.

> +	/*
> +	 * NEEDSWORK: In a multi-working-tree world this needs to be
> +	 * set in the per-worktree config.
> +	 */

So should we have a failing test for that scenario, or...? (Update: but
read ahead...)

> +static int add_config(int argc, const char **argv, const char *prefix)
> +{
> +	int force = 0;
> +	struct add_data add_data = ADD_DATA_INIT;
> +
> +	struct option options[] = {
> +		OPT_STRING('b', "branch", &add_data.branch,
> +			   N_("branch"),
> +			   N_("branch of repository to store in "
> +			      "the submodule configuration")),
> +		OPT_STRING(0, "url", &add_data.repo,
> +			   N_("string"),
> +			   N_("url to clone submodule from")),
> +		OPT_STRING(0, "resolved-url", &add_data.realrepo,
> +			   N_("string"),
> +			   N_("url to clone the submodule from, after it has "
> +			      "been dereferenced relative to parent's url, "
> +			      "in the case where <url> is a relative url")),
> +		OPT_STRING(0, "path", &add_data.sm_path,
> +			   N_("path"),
> +			   N_("where the new submodule will be cloned to")),
> +		OPT_STRING(0, "name", &add_data.sm_name,
> +			   N_("string"),
> +			   N_("name of the new submodule")),
> +		OPT__FORCE(&force, N_("allow adding an otherwise ignored submodule path"),
> +			   PARSE_OPT_NOCOMPLETE),
> +		OPT_END()
> +	};
> +
> +	const char *const usage[] = {
> +		N_("git submodule--helper add-config "
> +		   "[--force|-f] [--branch|-b <branch>] "
> +		   "--url <url> --resolved-url <resolved-url> "
> +		   "--path <path> --name <name>"),
> +		NULL
> +	};

I'd say consider adding this as a "static" earlier in the file, but it's
an established pattern in this file, so let's keep it.

> +	argc = parse_options(argc, argv, prefix, options, usage, 0);

It's fine to omit it for a helper, but we're being non-pedantic about
checking mandatory options here. Would do it in a "real" built-in, but
for internal use it's fine.

> +	if (argc != 0)

Style: if (!argc)

> +		usage_with_options(usage, options);
> +
> +	add_data.force = !!force;
> +	configure_added_submodule(&add_data);
> +
> +	return 0;
> +}
> +
>  #define SUPPORT_SUPER_PREFIX (1<<0)
>  
>  struct cmd_struct {
> @@ -2949,6 +3073,7 @@ static struct cmd_struct commands[] = {
>  	{"name", module_name, 0},
>  	{"clone", module_clone, 0},
>  	{"add-clone", add_clone, 0},
> +	{"add-config", add_config, 0},
>  	{"update-module-mode", module_update_module_mode, 0},
>  	{"update-clone", update_clone, 0},
>  	{"ensure-core-worktree", ensure_core_worktree, 0},
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 053daf3724..f713cb113c 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -242,33 +242,7 @@ cmd_add()
>  	fi
>  
>  	git submodule--helper add-clone ${GIT_QUIET:+--quiet} ${force:+"--force"} ${progress:+"--progress"} ${branch:+--branch "$branch"} --prefix "$wt_prefix" --path "$sm_path" --name "$sm_name" --url "$realrepo" ${reference:+"$reference"} ${dissociate:+"--dissociate"} ${depth:+"$depth"} || exit
> -	git config submodule."$sm_name".url "$realrepo"
> -
> -	git add --no-warn-embedded-repo $force "$sm_path" ||
> -	die "fatal: $(eval_gettext "Failed to add submodule '\$sm_path'")"
> -
> -	git submodule--helper config submodule."$sm_name".path "$sm_path" &&
> -	git submodule--helper config submodule."$sm_name".url "$repo" &&
> -	if test -n "$branch"
> -	then
> -		git submodule--helper config submodule."$sm_name".branch "$branch"
> -	fi &&
> -	git add --force .gitmodules ||
> -	die "fatal: $(eval_gettext "Failed to register submodule '\$sm_path'")"
> -
> -	# NEEDSWORK: In a multi-working-tree world, this needs to be
> -	# set in the per-worktree config.

Ah, this is the NEEDSWORK comment, just copied to the C code...

> -	if git config --get submodule.active >/dev/null
> -	then
> -		# If the submodule being adding isn't already covered by the
> -		# current configured pathspec, set the submodule's active flag
> -		if ! git submodule--helper is-active "$sm_path"
> -		then
> -			git config submodule."$sm_name".active "true"
> -		fi
> -	else
> -		git config submodule."$sm_name".active "true"
> -	fi
> +	git submodule--helper add-config ${force:+--force} ${branch:+--branch "$branch"} --url "$repo" --resolved-url "$realrepo" --path "$sm_path" --name "$sm_name"
>  }
>  

Very nice to have this simplified.

Would be good to split this very long line across multiple lines
though...

  parent reply	other threads:[~2021-07-22 11:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-22 11:21 [GSoC] [PATCH] submodule--helper: introduce add-config subcommand Atharva Raykar
2021-07-22 11:41 ` Atharva Raykar
2021-07-22 11:50 ` Ævar Arnfjörð Bjarmason [this message]
2021-07-22 13:28   ` Atharva Raykar
2021-07-22 13:31 ` Atharva Raykar
2021-07-23 20:36 ` Junio C Hamano
2021-07-24  9:59   ` Atharva Raykar
2021-07-28 11:53 ` [GSoC] [PATCH v2] " Atharva Raykar
2021-07-28 19:51   ` Kaartic Sivaraam
     [not found]     ` <d206fa7a-a450-552b-824c-518ee481c480@gmail.com>
2021-07-29 19:30       ` Kaartic Sivaraam
2021-07-30  6:22         ` Atharva Raykar
2021-08-01  6:33   ` [GSoC] [PATCH v3] " Atharva Raykar
2021-08-05 18:25     ` Kaartic Sivaraam

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=87sg06tvab.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=congdanhqx@gmail.com \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=kaartic.sivaraam@gmail.com \
    --cc=pc44800@gmail.com \
    --cc=periperidip@gmail.com \
    --cc=rafaeloliveira.cs@gmail.com \
    --cc=raykar.ath@gmail.com \
    --cc=sunshine@sunshineco.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).