From: Palmer Dabbelt Date: Sat, 14 Sep 2019 13:58:37 GMT Subject: Re: pd/fetch-jobs, was Re: What's cooking in git.git (Sep 2019, #01; Sat, 7) Message-ID: In-Reply-To: On Thu, 12 Sep 2019 11:02:42 PDT (-0700), gitster@pobox.com wrote: > Johannes Schindelin 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=` 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.