On Wed, Nov 11, 2015 at 11:55 AM, Jens Lehmann <Jens.Lehmann@xxxxxx> wrote: >> >> 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? Actually I don't think that far ahead. (I assume network to be the bottleneck for clone/fetch operations) All I want is a saturated network all the time, and as the native git protocol doesn't provide that (tcp startup takes time until full band witdth is reached, local operations both on client and server) I added the parallel stuff to 'smear' different submodule network traffics along the timeline, such that we have a better approximation of an always fully saturated link for the whole operation. So in the long term future, we maybe want to reuse an http/ssh session for a different submodule, possibly interleaving the different submodules on the wire to make it even faster. Though that may not be helping much. So we're back at bike shedding about the name. submodule.fetchJobs sounds like it only applies to fetching, do you think it's sufficient for clone as well? Once upon a time, Junio used 'submodule.fetchParallel' or 'submodule.paralle' in a discussion[1] for the distinction of the local and networked things. [1] Discussing "[PATCH] Add fetch.recurseSubmoduleParallelism config option" How about submodules.parallelNetwork for the networking part and submodules.parallelLocal for the local part? (I don't implement parallelLocal in the next few weeks I'd estimate). -- 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