Am 10.11.2015 um 23:29 schrieb Stefan Beller:
On Tue, Nov 10, 2015 at 2:21 PM, Jens Lehmann <Jens.Lehmann@xxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html