Re: [PATCH v2 5/5] fetch: Make --jobs control submodules and remotes
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 13, 2019, 22:00 UTC
- Message-ID
- <xmqq7e7g7mky.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <20190812213448.2649-6-palmer@sifive.com>
Palmer Dabbelt <palmer@sifive.com> writes:
Show 8 quoted lines
> The existing --jobs argument was defined to control the number of jobs
> used for submodule fetching, but it makes more sense to have this
> argument control the number of jobs to be used when fetching from
> multiple remotes as well.
>
> This patch simply changes the --jobs argument parsing code to set both
> max_children_for_{submodules,fetch}, as well as noting this new behavior
> in the documentation.That's a sensible, if overly careful, transition plan. This patch cannot be queued together with the other four, though, for the plan to be practical. It probably needs to come a few releases after the other four hits a release.
A less involved and much more careless transition plan may be to just declare that "--jobs that only controls submodule fetches is a bug and it must also affect how fetches from multiple remote repositories are done" and come directly to this step, without necessarily introducing options that control them independently.
I have a suspicion that we can afford to go the careless route for this particular one, if we wanted to, as not may people would care about controlling these independently.