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

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Jan 7, 2026, 23:38 UTC
Message-ID: <aV7ujZ2FeO7EleT5@fruit.crustytoothpaste.net>
In-Reply-To: <87secimchc.fsf@gmail.com>

On 2026-01-07 at 01:35:11, Collin Funk wrote:

Show 5 quoted lines

> 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