All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Matthias Aßhauer via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, "Drew Noakes" <drnoakes@microsoft.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Matthias Aßhauer" <mha1993@live.de>
Subject: Re: [PATCH] fetch: choose a sensible default with --jobs=0 again
Date: Tue, 21 Feb 2023 12:15:40 -0800	[thread overview]
Message-ID: <xmqqcz62epw3.fsf@gitster.g> (raw)
In-Reply-To: <pull.1483.git.1676928805555.gitgitgadget@gmail.com> ("Matthias Aßhauer via GitGitGadget"'s message of "Mon, 20 Feb 2023 21:33:25 +0000")

"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.

      reply	other threads:[~2023-02-21 20:15 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-20 21:33 [PATCH] fetch: choose a sensible default with --jobs=0 again Matthias Aßhauer via GitGitGadget
2023-02-21 20:15 ` Junio C Hamano [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqcz62epw3.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=avarab@gmail.com \
    --cc=drnoakes@microsoft.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=mha1993@live.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.