On Thu, Dec 13, 2018 at 6:17 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Sjon Hortensius <sjon@xxxxxxxx> writes: > > > When switching to 2.20 our `git submodule update' (which clones > > through ssh) broke because our ssh-server rejected the ~20 > > simultaneous connections the git-client makes. This seems to be caused > > by a (possibly unintended) change in > > https://github.com/git/git/commit/90efe595c53f4bb1851371344c35eff71f604d2b > > which removed the default of max_jobs=1 > > > > While this can easily be fixed by configuring submodule.fetchJobs I > > think this change should be documented - or reverted back to it's > > previous default of 1 > > The commit in question does not look like it _wanted_ to change the > default; rather, it appears to me that it wanted to be bug-to-bug > compatible with the original, and any such change of behaviour is > entirely unintended. Indeed. > I think the attached may be sufficient to change the default > max_jobs back to 1. I think so, too. I can wrap it into a commit with a proper message. > > By the way, is there a place where we document that the default > value for fetchjobs, when unconfigured, is 1? `man git config` submodule.fetchJobs Specifies how many submodules are fetched/cloned at the same time. A positive integer allows up to that number of submodules fetched in parallel. A value of 0 will give some reasonable default. If unset, it defaults to 1. and that seems to be the only place, other places only reference this place: Documentation$ git grep submodule.fetch config/submodule.txt:66:submodule.fetchJobs:: git-clone.txt:259: Defaults to the `submodule.fetchJobs` option. git-submodule.txt:408: Defaults to the `submodule.fetchJobs` option. The behavior of that seems to have been there since the beginning of a028a1930c (fetching submodules: respect `submodule.fetchJobs` config option, 2016-02-29) > If we are not making > such a concrete promise, then I would think it is OK to update the > default without any fanfare, as long as we have good reasons to do > so. For this particular one, however, as I already said, I do not > think we wanted to change the default to unlimited or anything like > that, so... We definitely want the diff below as a proper patch. > builtin/submodule--helper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c > index 789d00d87d..e8cdf84f1c 100644 > --- a/builtin/submodule--helper.c > +++ b/builtin/submodule--helper.c > @@ -1552,7 +1552,7 @@ struct submodule_update_clone { > #define SUBMODULE_UPDATE_CLONE_INIT {0, MODULE_LIST_INIT, 0, \ > SUBMODULE_UPDATE_STRATEGY_INIT, 0, 0, -1, STRING_LIST_INIT_DUP, 0, \ > NULL, NULL, NULL, \ > - NULL, 0, 0, 0, NULL, 0, 0, 0} > + NULL, 0, 0, 0, NULL, 0, 0, 1} > > > static void next_submodule_warn_missing(struct submodule_update_clone *suc,
