Re: [PATCH v2 3/7] fetch: avoid reading submodule config until needed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes:

> Teach "git fetch" to avoid reading the submodule config until necessary.
> This allows users to avoid the lazy-fetching of this potentially missing
> config file by specifying the --recurse-submodules=no command line
> option.
>
> Signed-off-by: Jonathan Tan <jonathantanmy@xxxxxxxxxx>
> ---
>  builtin/fetch.c    | 10 ++++++++--
>  submodule-config.c |  5 +++--
>  2 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/builtin/fetch.c b/builtin/fetch.c
> index a5498646bf..29db219c68 100644
> --- a/builtin/fetch.c
> +++ b/builtin/fetch.c
> @@ -1786,12 +1786,18 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
>  		free(anon);
>  	}
>  
> -	fetch_config_from_gitmodules(&submodule_fetch_jobs_config,
> -				     &recurse_submodules);
>  	git_config(git_fetch_config, NULL);
>  
>  	argc = parse_options(argc, argv, prefix,
>  			     builtin_fetch_options, builtin_fetch_usage, 0);
> +	if (recurse_submodules != RECURSE_SUBMODULES_OFF) {
> +		int *sfjc = submodule_fetch_jobs_config == -1
> +			    ? &submodule_fetch_jobs_config : NULL;
> +		int *rs = recurse_submodules == RECURSE_SUBMODULES_DEFAULT
> +			  ? &recurse_submodules : NULL;
> +
> +		fetch_config_from_gitmodules(sfjc, rs);
> +	}

Hmph.  Instead of calling fetch_config_from... upfront, first
reading the fetch configuration and also command line options to see
if we are told to recurse, and only enter the new "if()" statement
does make sense---we'll avoid calling fetch_config_from... when we
are told not to recurse into submodules.

But it is not quite clear why the two parameters to the function can
now be conditional, and what benefit we gain by doing so, in the
body of the new "if()" statement.  Don't you need to explain to your
future peer developers what is going on here in the log message?

>  	if (deepen_relative) {
>  		if (deepen_relative < 0)
> diff --git a/submodule-config.c b/submodule-config.c
> index e175dfbc38..8d65273ed2 100644
> --- a/submodule-config.c
> +++ b/submodule-config.c
> @@ -776,10 +776,11 @@ struct fetch_config {
>  static int gitmodules_fetch_config(const char *var, const char *value, void *cb)
>  {
>  	struct fetch_config *config = cb;
> -	if (!strcmp(var, "submodule.fetchjobs")) {
> +	if (!strcmp(var, "submodule.fetchjobs") && config->max_children) {
>  		*(config->max_children) = parse_submodule_fetchjobs(var, value);
>  		return 0;

Because the new "if()" statement in cmd_fetch can pass NULL to
either of the two parameters to fetch_config_from_gitmodules(), it
now becomes possible for this function to get an instance of "struct
fetch_config" with .max_children field set to NULL.

The above justifies why assignment to *(config->max_children) must
be skipped when .max_children is NULL, but it does not justify the
new code, where .max_children==NULL does not stop the if/else if/
cascade.

	if (!strcmp(var, "submodule.fetchjobs")) {
		if (config->max_children)
			*(config->max_children) = parse...
		return 0;
	}

Why sfjc or rs is allowed to be NULL in certain cases, and why doing
so is a good idea, should be explained nevertheless, though.

> -	} else if (!strcmp(var, "fetch.recursesubmodules")) {
> +	} else if (!strcmp(var, "fetch.recursesubmodules") &&
> +		   config->recurse_submodules) {
>  		*(config->recurse_submodules) = parse_fetch_recurse_submodules_arg(var, value);
>  		return 0;

Likewise.

Thanks.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux