Re: [PATCH v9 2/3] introduce submodule.hasSuperproject record
- From
Glen Choo <chooglen@google.com>
- Date
- Mar 10, 2022, 21:29 UTC
- Message-ID
- <kl6lczitsdhm.fsf@chooglen-macbookpro.roam.corp.google.com>
- In-Reply-To
- <xmqqtuc6h83m.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
Show 19 quoted lines
> Emily Shaffer <emilyshaffer@google.com> writes:
>
>> @@ -2617,6 +2622,12 @@ static int run_update_procedure(int argc, const char **argv, const char *prefix)
>>
>> free(prefixed_path);
>>
>> + /*
>> + * This entry point is always called from a submodule, so this is a
>> + * good place to set a hint that this repo is a submodule.
>> + */
>> + git_config_set("submodule.hasSuperproject", "true");
>> +
>> if (!oideq(&update_data.oid, &update_data.suboid) || update_data.force)
>> return do_run_update_procedure(&update_data);
>
> In Glen's update to rewrite "submodule update" in C, this part is
> replaced with a call to update_submodule2(). I am not sure what the
> current repository is at this point of the code with and without
> Glen's topic, but are we sure we are in a submodule we discovered?With my topic, this call would be moved into update_submodule2(). The repository at that point is the superproject.
Show 11 quoted lines
> builtin/submodule--helper.c::run_update_procedure() takes sm_path to > the path to the submodule, presumably from superproject's point of > view, and the callchain leads to a call to run_update_command() > eventually, which uses run_command_v_opt_cd_env() to go in to the > submodule repository and run an external git command (like > "checkout"), so it looks like what git_config_set() updates is the > superprojects' configuration, not the configuration of a particular > submodule being updated. > > The other one, where cmd_clone() sets the variable in submodule's > configuration file, looks good, but I am not sure about this one.
But in this series, the current repository is the submodule because this part happens in a "run-update-procedure" child process.
So there is a slight conflict here, but the conflict existed even before this change (we used to do this twice in git-submodule.sh and module_clone()).
Because of that conflict, I was planning to base "part2" on this series anyway, and if anything, this change makes the conflict better because we now set "submodule.hasSuperproject" in only one place (run_update_procedure()) instead of two.
So I think this change improves this series and improves the interaction with mine.