Re: pd/fetch-jobs, was Re: What's cooking in git.git (Sep 2019, #01; Sat, 7)

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 12, 2019, 18:02 UTC
Message-ID: <xmqq8sqtgzp9.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <nycvar.QRO.7.76.6.1909111359150.5377@tvgsbejvaqbjf.bet>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 15 quoted lines

>> * pd/fetch-jobs (2019-08-13) 5 commits
>>  . fetch: make --jobs control submodules and remotes
>>  . fetch: add the --submodule-fetch-jobs option
>>  . fetch: add the fetch.jobs config key
>>  . fetch: add the "--fetch-jobs" option
>>  . fetch: rename max_children to max_children_for_submodules
>>
>>  "git fetch --jobs" is getting taught to also run fetch jobs in
>>  parallel when fetching from multiple remote repositories.
>>
>>  Comments?
>
> I still stand by my suggestion that it is undesirable (and makes the
> code much more complicated than necessary) to end up with three options.
> Having only `--jobs=<n>` would be the ideal solution.

I think exposing "--jobs" as the primary UI element is a good longer term goal; the approach taken in the intermediate step would be a necessary one for backward compatibility.

I stopped carrying it in 'pu' some weeks ago (I suspect it had some interactions with other topics in flight, by causing either test failures or textual conflicts). Perhaps somebody interested enough in the topic can resurrect it.