Subject: Re: [PATCH] ignores: handle non UTF-8 exclude files

From: "brian m. carlson" <[email-masked]>
Date: Wed, 7 Jan 2026 23:38:53 +0000

On 2026-01-07 at 01:35:11, Collin Funk wrote:
> An unfortunate trend that I have seen with Rust programs is that they
> completely disregard the systems locale. E.g. using
> LC_ALL=en_US.ISO-8859-1 and passing an "À" character as an option will
> typically fail since it is encoded as 0xC0 which is not a valid UTF-8
> character.

Git does not usually directly read input and then convert it to other
encodings unless specifically asked to (e.g., `working-tree-encoding`),
so I fully expect that nothing will change there.  However, in many
cases, Git also currently does not honour LC_ALL, such as for commit
messages.

> I figured it was worth bringing up since Git may wany to think about it
> some before introducing more Rust. I think it can be worked around by
> using OsString [1], but I guess many people choose not to.

The people who have been working on Rust have been very careful to not
make assumptions that all data is UTF-8, and I don't expect that to
change.

OsString is slightly problematic because it is effectively UTF-8-ish (on
Windows, it's actually WTF-8 and on Unix it allows arbitrary bytes) but
there is no portable way to get any consistent byte encoding out of it.
(In versions of Rust too new for us to use, there is a function that
provides a byte encoding but it's not guaranteed to be stable across
versions.)  I have some custom code in one of my branches to handle the
conversion to and from OsString to a consistent byte encoding using some
traits to paper over the operating system differences.

In general, I expect we will continue to use some C-based interfaces
(possibly called via Rust wrappers) because Rust also does not expose
things like file descriptors on Windows or the full range of stat or
other information we need.

One assumption I do think is safe to make is that arbitrary Unicode can
be printed to the terminal, such as in error messages.  Considering that
virtually everybody sets IUTF8 in Unix terminals and we effectively do
that right now with localized text, I think that's okay.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA