Re: [PATCH 2/3] builtin/fetch: parse recurse-submodules-default at default options parsing
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 23, 2017, 22:36 UTC
- Message-ID
- <xmqqo9tebaco.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <20170623191302.16053-3-sbeller@google.com>
Stefan Beller <sbeller@google.com> writes:
Show 10 quoted lines
> @@ -1333,10 +1336,8 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
> deepen = 1;
>
> if (recurse_submodules != RECURSE_SUBMODULES_OFF) {
> - if (recurse_submodules_default) {
> - int arg = parse_fetch_recurse_submodules_arg("--recurse-submodules-default", recurse_submodules_default);
> - set_config_fetch_recurse_submodules(arg);
> - }
> + if (recurse_submodules_default != RECURSE_SUBMODULES_DEFAULT)
> + set_config_fetch_recurse_submodules(recurse_submodules_default);This is not a new thing, and it may not even be a problem, but I have to wonder why this needs to be done conditionally. "The command line did not explicitly say --no-recurse-submodules, so we would set what came from --recurse-submodule-default if and only if that is given---otherwise we leave it as a compiled-in default" is what the code before or after this patch tells me. But if we drop the "if (default is not DEFAULT)", the resulting code becomes "The command line did not explicitly say --no-recurse-submodules, so we would set whatever is the default (which may not have been given from the command line, but came built-in to the binary)". Aren't they saying the same thing?
It's not like there is a configuration knob that further interferes the interaction between these two. I am puzzled.
> gitmodules_config(); > git_config(submodule_config, NULL); > }