Re: [PATCH v5 12/12] bundle-uri: suppress stderr from remote-https

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 26, 2022, 18:54 UTC
Message-ID: <xmqqmt9ih0um.fsf@gitster.g>
In-Reply-To: <5729ff2af4bb56a68624b7942b8afa67601adb43.1665579160.git.gitgitgadget@gmail.com>

"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 20 quoted lines

> From: Derrick Stolee <derrickstolee@github.com>
>
> When downloading bundles from a git-remote-https subprocess, the bundle
> URI logic wants to be opportunistic and download as much as possible and
> work with what did succeed. This is particularly important in the "any"
> mode, where any single bundle success will work.
>
> If the URI is not available, the git-remote-https process will die()
> with a "fatal:" error message, even though that error is not actually
> fatal to the super process. Since stderr is passed through, it looks
> like a fatal error to the user.
>
> Suppress stderr to avoid these errors from bubbling to the surface. The
> bundle URI API adds its own warning() messages on these failures.
>
> Signed-off-by: Derrick Stolee <derrickstolee@github.com>
> ---
>  bundle-uri.c                |  1 +
>  t/t5558-clone-bundle-uri.sh | 16 ++++++++++++++--
>  2 files changed, 15 insertions(+), 2 deletions(-)

So this is the same in spirit as [11/12] to squelch errors from an action that we are prepared to fail. If we had an easy way to squelch only one class of errors (e.g. the resource no longer exists at the URI) while allowing others to pass (e.g. we downloaded but it was corrupt), that might be even better when somebody is debugging the thing, but to an end user, it is a hopefully ignorable failure either way, as long as there are other alternatives in the set of bundles in the "any" mode.