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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.








[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux