From: "Jean-Noël AVILA" <avila.jn@gmail.com>
To: git@vger.kernel.org, Paulius Zaleckas <paulius.zaleckas@gmail.com>
Cc: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Subject: Re: [PATCH 2/2] fetch: add fetch.submoduleErrors to make submodule fetch errors non-fatal
Date: Tue, 31 Mar 2026 18:44:49 +0200 [thread overview]
Message-ID: <2285132.irdbgypaU6@piment-oiseau> (raw)
In-Reply-To: <20260330173938.3792358-3-paulius.zaleckas@gmail.com>
On Monday, 30 March 2026 19:39:38 CEST Paulius Zaleckas wrote:
> When fetching with --recurse-submodules, a submodule commit that is not
> yet reachable from any of the submodule's remote refs causes the entire
> fetch to fail. This is overly strict when the missing commit belongs to
> an upstream branch that is still being prepared (e.g. an in-progress
> merge topic): the local branch does not need that commit, so there is no
> reason to treat its absence as fatal.
>
> Add a new config key fetch.submoduleErrors (values: fail/warn) and a
> corresponding --submodule-errors=<fail|warn> command-line option that
> control this behaviour. The default remains fail (existing behaviour);
> setting the value to warn causes submodule fetch failures to be reported
> on stderr without affecting the overall exit status of git fetch / git
> pull.
>
> Signed-off-by: Paulius Zaleckas <paulius.zaleckas@gmail.com>
> ---
> Documentation/config/fetch.adoc | 14 +++++
> builtin/fetch.c | 39 +++++++++++++-
> submodule.c | 8 ++-
> submodule.h | 7 ++-
> t/t5526-fetch-submodules.sh | 96 +++++++++++++++++++++++++++++++++
> 5 files changed, 160 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/config/fetch.adoc b/Documentation/config/
fetch.adoc
> index cd40db0cad..8a6b68e57e 100644
> --- a/Documentation/config/fetch.adoc
> +++ b/Documentation/config/fetch.adoc
> @@ -1,3 +1,17 @@
> +`fetch.submoduleErrors`::
> + Controls how errors from submodule fetches are handled when
> + `--recurse-submodules` is in effect. When set to `fail` (the
default),
> + any submodule fetch error causes the overall `git fetch` or `git
pull`
> + to exit with a non-zero status. When set to `warn`, submodule fetch
> + errors are reported to stderr but do not affect the exit status of
the
> + command. This is useful when working in repositories where some
> + branches reference submodule commits that are not yet available on
the
> + submodule remote, but those commits are not needed for the currently
> + checked-out branch.
> ++
> +The value of this option can be overridden on the command line with
> +`--submodule-errors=<fail|warn>`.
These `fail` and `warn` are keywords, so the alternatives must be expressed in
synopsis style as `--submodule-errors=(fail|warn)`
I also failed to find the documentation for this `--submodule-errors` option.
Could you add it in the relevant manual pages?
> +
> `fetch.recurseSubmodules`::
> This option controls whether `git fetch` (and the underlying fetch
> in `git pull`) will recursively fetch into populated submodules.
prev parent reply other threads:[~2026-03-31 16:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-30 17:39 [PATCH 0/2] fetch: make submodule fetch errors configurable Paulius Zaleckas
2026-03-30 17:39 ` [PATCH 1/2] submodule: fix premature failure in recursive submodule fetch Paulius Zaleckas
2026-03-30 17:39 ` [PATCH 2/2] fetch: add fetch.submoduleErrors to make submodule fetch errors non-fatal Paulius Zaleckas
2026-03-31 16:44 ` Jean-Noël AVILA [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=2285132.irdbgypaU6@piment-oiseau \
--to=avila.jn@gmail.com \
--cc=git@vger.kernel.org \
--cc=paulius.zaleckas@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox