Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
> On Mon, Jun 27 2022, Glen Choo via GitGitGadget wrote:
>
>> From: Glen Choo <chooglen@xxxxxxxxxx>
>>
>> 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.
Ah good point. This was an oversight actually; I initially based this
off ab/submodule-cleanup, but decided to make it standalone. Thanks for
spotting the mistake.
At any rate, I'm quite sure that ab/submodule-cleanup v5 is ready for
'next', so I'll rebase this.
>> 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 :)
Yes. Sigh..
It looks like "--histogram" produces the diff I'd want:
enum submodule_update_type update_type = update_data->update_default;
+ if (update_data->displaypath)
+ 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);
- if (update_data->displaypath)
- strvec_pushf(args, "--recursive-prefix=%s/",
- update_data->displaypath);
but that probably means I'd need to give up on GGG :/ (which I've grown
to like despite its shortcomings).
>> @@ -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
Very interesting, thanks for sharing :) I'll take your suggestion to
cherry-pick f445c57490d.
