All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Beller <sbeller@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Brandon Williams <bmwill@google.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Philip Oakley <philipoakley@iee.org>
Subject: Re: [PATCH 2/3] builtin/fetch: parse recurse-submodules-default at default options parsing
Date: Fri, 23 Jun 2017 15:49:54 -0700	[thread overview]
Message-ID: <CAGZ79ka+va5bRNQL3x3fvn+738iAfJXJfD2PKpt2hmGEg09mTQ@mail.gmail.com> (raw)
In-Reply-To: <xmqqo9tebaco.fsf@gitster.mtv.corp.google.com>

On Fri, Jun 23, 2017 at 3:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Stefan Beller <sbeller@google.com> writes:
>
>> @@ -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?

I assumed so as well, yes. But the test suite pointed out there
is another subtlety going on, which I have not dug into, yet.

>
> It's not like there is a configuration knob that further interferes
> the interaction between these two.  I am puzzled.

As far as I suspect, the original author considered
evaluating the additional config too expensive.

    gitmodules_config(); // <- this specifically?
    git_config(submodule_config, NULL);

And that is why we only react if any switch is
given to recurse. Before be254a0ea9 (Add the
'fetch.recurseSubmodules' config setting, 2010-11-11)
we would not load the config unless the user
asked for submodule action.

Then with the config switch we *had* to load the config
(both .gitmodules as well as .git/config), so at that commit
it would have made sense to inline this into the regular config
and command line argument parsing.

  reply	other threads:[~2017-06-23 22:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-23 19:12 [PATCH 0/3] pull: optionally rebase submodules Stefan Beller
2017-06-23 19:13 ` [PATCH 1/3] builtin/fetch: factor submodule recurse parsing out to submodule config Stefan Beller
2017-06-23 22:26   ` Junio C Hamano
2017-06-23 19:13 ` [PATCH 2/3] builtin/fetch: parse recurse-submodules-default at default options parsing Stefan Beller
2017-06-23 22:36   ` Junio C Hamano
2017-06-23 22:49     ` Stefan Beller [this message]
2017-06-24  0:51       ` Junio C Hamano
2017-06-27  3:00         ` Stefan Beller
2017-06-27 21:31           ` [PATCH] builtin/fetch cleanup: always set default value for submodule recursing Stefan Beller
2017-06-23 19:13 ` [PATCH 3/3] pull: optionally rebase submodules (remote submodule changes only) Stefan Beller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGZ79ka+va5bRNQL3x3fvn+738iAfJXJfD2PKpt2hmGEg09mTQ@mail.gmail.com \
    --to=sbeller@google.com \
    --cc=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=philipoakley@iee.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.