fetch: choose a sensible default with --jobs=0 again

[rimrul]

Prior to 51243f9 (run-command API: don't fall back on online_cpus(), 2022-10-12) git fetch --multiple --jobs=0 would choose some default amount of jobs, similar to git -c fetch.parallel=0 fetch --multiple. While our documentation only ever promised that fetch.parallel would fall back to a "sensible default", it makes sense to do the same for --jobs. So fall back to online_cpus() and not BUG() out.

This was originally reported at https://lore.kernel.org/git/PSAP153MB03910458707331B64FA7460DCAA19@PSAP153MB0391.APCP153.PROD.OUTLOOK.COM/T/#u

cc: Drew Noakes drnoakes@microsoft.com
cc: Ævar Arnfjörð Bjarmason avarab@gmail.com

[rimrul]

What's happening with win test (8) why is that job at almost 5h?

[rimrul]

/submit

[gitgitgadget]

Submitted as pull.1483.git.1676928805555.gitgitgadget@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-1483/rimrul/fix-fetch-jobs-0-v1

To fetch this version to local tag pr-1483/rimrul/fix-fetch-jobs-0-v1:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-1483/rimrul/fix-fetch-jobs-0-v1

[gitgitgadget]

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Matthias Aßhauer via GitGitGadget"  <gitgitgadget@gmail.com>
writes:

> From: =?UTF-8?q?Matthias=20A=C3=9Fhauer?= <mha1993@live.de>
>
> prior to 51243f9 (run-command API: don't fall back on online_cpus(),
> 2022-10-12) `git fetch --multiple --jobs=0` would choose some default amount
> of jobs, similar to `git -c fetch.parallel=0 fetch --multiple`. While our
> documentation only ever promised that `fetch.parallel` would fall back to a
> "sensible default", it makes sense to do the same for `--jobs`. So fall back
> to online_cpus() and not BUG() out.

Yup, the way I read 51243f9f (run-command API: don't fall back on
online_cpus(), 2022-10-12) is that it wanted to make it a best
practice for the callers of the API to be making an explicit choice
of scaling with online_cpus() or other metrics depending on their
needs.  The problematic commit does touch some fetch-related code
paths and make them call online_cpus() themselves, so we probably
are looking at an inadequate tests, and this is a fix that is in
line of the spirit, completing what 51243f9f started to do.

Thanks, will queue.

[gitgitgadget]

This branch is now known as ma/fetch-parallel-use-online-cpus.

[gitgitgadget]

This patch series was integrated into seen via git@d964f78.

[dscho]

What's happening with win test (8) why is that job at almost 5h?

@rimrul most likely a hang in the MSYS2 runtime, seeing as the push variant of the same job succeeded in 7 minutes. I started a re-run.

[gitgitgadget]

This patch series was integrated into seen via git@9e68d32.

[gitgitgadget]

This patch series was integrated into next via git@756d379.

[gitgitgadget]

There was a status update in the "New Topics" section about the branch ma/fetch-parallel-use-online-cpus on the Git mailing list:

"git fetch --jobs=0" used to hit a BUG(), which has been corrected
to use the available CPUs.

Will merge to 'master'.
source: <pull.1483.git.1676928805555.gitgitgadget@gmail.com>

[gitgitgadget]

This patch series was integrated into seen via git@efd5b0b.

[gitgitgadget]

This patch series was integrated into seen via git@0ad6bdb.

[gitgitgadget]

There was a status update in the "Cooking" section about the branch ma/fetch-parallel-use-online-cpus on the Git mailing list:

"git fetch --jobs=0" used to hit a BUG(), which has been corrected
to use the available CPUs.

Will merge to 'master'.
source: <pull.1483.git.1676928805555.gitgitgadget@gmail.com>

[gitgitgadget]

This patch series was integrated into seen via git@72ab6df.

[gitgitgadget]

This patch series was integrated into seen via git@d180cc2.

[gitgitgadget]

This patch series was integrated into master via git@d180cc2.

[gitgitgadget]

This patch series was integrated into next via git@d180cc2.

[gitgitgadget]

Closed via d180cc2.