Stefan Beller <sbeller@xxxxxxxxxx> writes:
> so maybe
> fetch.recurseSubmoduleJobs
> fetch.submoduleJobs
> fetch.jobs
> fetch.connectionsToUse
"git remote update" is another example that may want to run multiple
independent 'git fetch' in parallel. I think "When the operation I
ask involves fetching from multiple places, I want N instances of
them to be executed", regardless of the kind of operation ("remote
update" or "submodule update", etc.), would match the end-user's
point of view the best, if you want to give them "set this single
thing to apply to all of them" fallback default.
If you want to give them a finer-grained control, you would need to
differentiate what kind of fetch would use N tasks (as opposed to
other kind of fetch that uses M tasks) and the name would need to
have "submodule" in it for that differentiation.
>> So if you want
>>
>> [submodule]
>> fetchParallel = 16
>> updateParallel = 4
>
> So you would have different settings here for only slightly different things?
I was just showing you that it is _possible_ if you want to give
finer control. For example, you can define:
* 'submodule.parallel', if defined gives the values for the
following more specific ones if they aren't given.
* 'submodule.fetchParallel' specifies how many tasks are run in
'fetch --recurse-submodules'.
* 'submodule.fetchParallel' specifies how many tasks are run in
'submodule update'.
so that those who want finer controls can, and those who don't can
set a single one to apply to all.
If you want to start with a globally single setting, that is
perfectly fine.
--
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