From: Stefan Beller <sbeller@google.com>
Date: Wed, 28 Oct 2015 20:50:43 GMT
Subject: Re: [PATCH 6/9] clone: allow an explicit argument for parallel submodule clones
Message-ID: <CAGZ79kauFzSKHnUyUPB29Lu59FODVXG5wxWfGK+v7UCAUuESJQ@mail.gmail.com>
In-Reply-To: <xmqqlhaoni6q.fsf@gitster.mtv.corp.google.com>

On Tue, Oct 27, 2015 at 1:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> +     The number of submodules fetched at the same time.
>
> Do we want to say "Defaults to submodule.jobs" somewhere?

Yes. :)

> I am tempted to suggest that you should not pay attention to
> "submodule.jobs" in this command at all and just pass through
> "--jobs=$max_jobs" that was specified from the command line, as the
> spawned "submodule update --init --recursive" would handle
> "submodule.jobs" itself.

makes sense.

>
> Once you start allowing "clone.jobs" as a more specific version of
> "submodule.jobs", then reading max_jobs first from "clone.jobs" and
> then from the command line starts to make sense.  When neither is
> specified, you would spawn "submodule update --init --recursive"
> without any explicit "-j N" and let it honor its more generic
> "submodule.jobs" setting; otherwise, you would run it with "-j N" to
> override that more generic "submodule.jobs" setting with either the
> value the command line -j given to "clone" or specified by a more
> specific "clone.jobs".

I see. Though I do not plan adding clone.jobs in the near future.