On Thu, 12 Sep 2019 11:02:42 PDT (-0700), gitster@xxxxxxxxx wrote:
Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
* 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.
Sorry, I'm somewhat new to the git development process. I'm happy to re-spin
the patch set, I'm just not sure what do to here. It looks like there are some
test failures when I rebase to the latest master, which I'm happy to fix. Just
let me know if I should:
* Send all 5 patches, under the assumption that the last one will not get
merged until some time later.
* Send just the first 4 patches, holding onto the last one for later.
* Send just a single patch, which wouldn't add the --fetch-jobs and
--submodule-fetch-jobs arguments.
