From: Jens Lehmann Date: Wed, 11 Nov 2015 19:55:10 GMT Subject: Re: [PATCHv3 08/11] fetching submodules: respect `submodule.jobs` config option Message-ID: <56439D1E.8080102@web.de> In-Reply-To: Am 10.11.2015 um 23:29 schrieb Stefan Beller: > On Tue, Nov 10, 2015 at 2:21 PM, Jens Lehmann wrote: >>> +submodule.jobs:: >>> + This is used to determine how many submodules can be operated on in >>> + parallel. Specifying a positive integer allows up to that number >>> + of submodules being fetched in parallel. This is used in fetch >>> + and clone operations only. A value of 0 will give some reasonable >>> + configuration. It defaults to 1. >>> + >> >> >> Just curious (and sorry if this has already been discussed and I missed >> it, but the volume of your output is too much for my current git time >> budget ;-): While this config is for fetching only, do I recall correctly >> that you have plans to do submodule work tree updates in parallel too? >> If so, would it make sense to have different settings for fetching and >> updating? > > TL;DR: checkout is serial, network-related stuff only will be using > submodule.jobs My point being: isn't "jobs" a bit too generic for a config option that is only relevant for network-related stuff? Maybe "submodule.fetchJobs" or similar would be better, as you are already thinking about adding other parallelisms with different constraints later? > In the next series (origin/sb/submodule-parallel-update) this is reused for > fetches, clones, so only the network stuff. The checkout (as all local > operations) > is still done serially, as then you don't run into problems in > parallel at the same time. > (checkouts may be parallelized but I haven't done that yet, and postpone that > until it has settled a bit more) Makes sense.