Re: [PATCH 1/4] t4xxx: don't use iconv(1) without ICONV prereq

On Tue, Feb 10, 2026 at 12:14:01PM +0100, Torsten Bögershausen wrote:

On Mon, Feb 09, 2026 at 09:55:10AM -0800, Junio C Hamano wrote:

quoted

Patrick Steinhardt [off-list ref] writes:

quoted

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

Yeah, agreed. I was wondering whether I should have another preparatory
commit that deduplicates the logic, but ultimately I cared more about
fixing the CI failures that we currrently face.

quoted

quoted

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?  

In case the ICONV prereq is false we set up "UTF-8" as test encoding.
And UTF-8 is also the default encoding that we also specify in case the
above configuration hasn't been set, see `get_commit_output_encoding()`.
So this would essentially be a no-op and is expected to behave the exact
same as if the configuration wasn't set.

quoted

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.

The thing is that many of the tests are actually things that we really
want to test regardless of whether or not we have the ICONV prereq. They
aren't inherently specific to any specific encoding, even though we
_also_ verify that the encoding works as expected.

I didn't want to decrease test coverage, so I tried to only add ICONV
prerequisites where tests couldn't be trivially made to pass without the
binary.

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

Yeah, this change in GfW is indeed the root cause of the CI failures.
But even if the iconv binary were to come back I think it's somewhat
sensible to assume that the iconv(1) binary may not exist when built
with NO_ICONV. There might for example be platforms out there that have
no iconv support at all, and the patches in this series would help
those.

Thanks!

Patrick