From: Torsten Bögershausen <tboegi@web.de>
Date: Tue, 10 Feb 2026 11:14:01 GMT
Subject: Re: [PATCH 1/4] t4xxx: don't use iconv(1) without ICONV prereq
Message-ID: <20260210111401.GA27953@tb-raspi4>
In-Reply-To: <xmqq4inp6bup.fsf@gitster.g>

On Mon, Feb 09, 2026 at 09:55:10AM -0800, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > We've got a couple of tests that all use the iconv(1) executable to
> > convert the encoding of a commit message. All of these tests are
> > prepared to handle a missing ICONV prereq, in which case they will
> > simply use UTF-8 encoding.
> >
> > But even if the ICONV prerequisite has failed we try to use the iconv(1)
> > executable. But it's not a safe to assume that the executable exists in
> > that case. And besides that, it's also unnecessary to use iconv(1) in
> > the first place, as we would only use it to convert from UTF-8 to UTF-8,
> > which should be equivalent to a no-op.
> >
> > Fix the issue and skip the call to iconv(1) in case the prerequisite is
> > not set. This makes tests work on systems that don't have iconv at all.
> >
> > Note that arguably, it's even unsafe to assume that the iconv(1)
> > executable exists only because Git has been built with support for it.
> > A more wholistic approach would thus be to split up the ICONV prereq
> > into two prereqs: one that tells us whether Git has been built with
> > ICONV support, and one that tells us whether the iconv(1) executable
> > exists. But that would lead to a bunch of changes throughout our tests,
> > and for arguably negligible benefit.
> >
> > Signed-off-by: Patrick Steinhardt <ps@pks.im>
> > ---
> >  t/t4041-diff-submodule-option.sh             | 8 ++++++--
> >  t/t4059-diff-submodule-not-initialized.sh    | 8 ++++++--
> >  t/t4060-diff-submodule-option-diff-format.sh | 8 ++++++--
> >  3 files changed, 18 insertions(+), 6 deletions(-)
> 
> The repetition across three files look a bit disturbing X-<.
> 
> > diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041-diff-submodule-option.sh
> > index 4d4aa1650f..4dd4954260 100755
> > --- a/t/t4041-diff-submodule-option.sh
> > +++ b/t/t4041-diff-submodule-option.sh
> > @@ -37,8 +37,12 @@ add_file () {
> >  			test_tick &&
> >  			# "git commit -m" would break MinGW, as Windows refuse to pass
> >  			# $test_encoding encoded parameter to git.
> > -			echo "Add $name ($added $name)" | iconv -f utf-8 -t $test_encoding |
> > -			git -c "i18n.commitEncoding=$test_encoding" commit -F -
> > +			message="Add $name ($added $name)" &&
> > +			if test_have_prereq ICONV
> > +			then
> > +				message=$(echo "$message" | iconv -f utf-8 -t $test_encoding)
> > +			fi &&
> > +			echo "$message" | git -c "i18n.commitEncoding=$test_encoding" commit -F -
> 
> This was a bit unexpected.  Do we give any guarantee to builds that
> lack iconv support that "git -c i18n.commitEncoding=... commit" will
> pass the payload verbatim?  I would have expected ICONV prerequisite
> is used on the whole test_expect_success to exclude the tests that
> are affected, not at such a low level.
> 

To my understanding there are 2 different things:
- Does the platform have libiconv (which is linked into Git,
   and handles the commit encoding)
- Does the platform ship the iconv binary ?
  It seems as if mingw has stopped to ship the iconv binary.
  And as a result, Git for Windows is missing it, too.

(And if someone asks me: it probably makes sense to bring it back)

https://github.com/git-for-windows/git/issues/6083