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