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. I think the attached may be sufficient to change the default max_jobs back to 1. By the way, is there a place where we document that the default value for fetchjobs, when unconfigured, is 1? 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... 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,
