Re: [PATCH 4/5] submodule--helper update: use --super-prefix

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jun 28, 2022, 08:47 UTC
Message-ID: <220628.86wnd1f9t1.gmgdl@evledraar.gmail.com>
In-Reply-To: <57988287fc01a8baf5c4fd7326772c80bc015f3c.1656372017.git.gitgitgadget@gmail.com>

On Mon, Jun 27 2022, Glen Choo via GitGitGadget wrote:

Show 7 quoted lines

> From: Glen Choo <chooglen@google.com>
>
> Unlike the other subcommands, "git submodule--helper update" uses the
> "--recursive-prefix" flag instead of "--super-prefix". The two flags are
> otherwise identical (they only serve to compute the 'display path' of a
> submodule), except that there is a dedicated helper function to get the
> value of "--super-prefix".

This is a good change, it was slightly confusing that --recursive-prefix is left in git-submodule.sh after this, but then I remembered that I removed it in my ab/submodule-cleanup, and you were presumably trying to avoid the conflict.

Still, I think it's probably better to either base this on my series (re-roll incoming), or take make this truly stand-alone, and have Junio sort out the minor conflict.

Show 10 quoted lines

>  static void update_data_to_args(struct update_data *update_data, struct strvec *args)
>  {
> -	strvec_pushl(args, "submodule--helper", "update", "--recursive", NULL);
> -	strvec_pushf(args, "--jobs=%d", update_data->max_jobs);
>  	if (update_data->displaypath)
> -		strvec_pushf(args, "--recursive-prefix=%s/",
> +		strvec_pushf(args, "--super-prefix=%s/",
>  			     update_data->displaypath);
> +	strvec_pushl(args, "submodule--helper", "update", "--recursive", NULL);
> +	strvec_pushf(args, "--jobs=%d", update_data->max_jobs);

I did a double-take at this, but it's just one of these cases where "diff" is being overly helpful in trying to find us the most minimal diff possible :)

Show 12 quoted lines

> @@ -3352,9 +3342,9 @@ struct cmd_struct {
>  static struct cmd_struct commands[] = {
>  	{"list", module_list, 0},
>  	{"name", module_name, 0},
> -	{"clone", module_clone, 0},
> +	{"clone", module_clone, SUPPORT_SUPER_PREFIX},
>  	{"add", module_add, SUPPORT_SUPER_PREFIX},
> -	{"update", module_update, 0},
> +	{"update", module_update, SUPPORT_SUPER_PREFIX},
>  	{"resolve-relative-url-test", resolve_relative_url_test, 0},
>  	{"foreach", module_foreach, SUPPORT_SUPER_PREFIX},
>  	{"init", module_init, SUPPORT_SUPER_PREFIX},

I did my own spelunking into --super-prefix recently, and went a bit overboard, I don't think I'll ever submit all of these, but they're in my avar/git github fork:

	f445c57490d (submodule--helper: remove unused SUPPORT_SUPER_PREFIX flags, 2022-06-27)
	bac3def78e9 (submodule--helper.c: remove unnecessary ", 0" in init, 2022-06-27)
	af03aa2ad40 (submodule--helper.c: create a command dispatch helper, 2022-06-27)
	952fdec4cc0 (submodule--helper.c: make "support super prefix" a bitfield, not a flag, 2022-06-09)
	2d30186e633 (cocci: don't use strvec_pushl() if strvec_push() will do, 2022-06-27)
	8aa7e049360 (git.c: die earlier on bad "--super-prefix" combined with "-h", 2022-06-27)
	b0d324e9ad2 (git: make --super-prefix truly internal-only, BUG() on misuse, 2022-06-27)

So, this is a digressio, but after doing those I figured we could eventually get rid of --super-prefix, but it'll require some more make-things-a-built-in, or make-things-a-library.

But I think out of those perhaps you'd be interested in cherry-picking f445c57490d (submodule--helper: remove unused SUPPORT_SUPER_PREFIX flags, 2022-06-27) before this 4/5? I.e. before adding a new SUPPORT_SUPER_PREFIX flag we can remove it from those commands that don't use it, which clears things up a bit.

The others are all mostly unrelated cleanup, and I'm only noting them in case you're overly curious. A web view for f445c57490d is at: https://github.com/avar/git/commit/f445c57490d