Subject: Re: [RFC] Support UTF-8 characters in Git alias names

From: "brian m. carlson" <[email-masked]>
Date: Sun, 8 Feb 2026 23:21:30 +0000

On 2026-02-08 at 15:30:02, Jonatan Holmgren wrote:
> I think the best approach is to support UTF-8 specifically for alias.*
> variables, which would mean modifying the git_config_parse_key() fn to allow
> UTF-8 bytes and make non-ascii aliases case-sensitive to avoid complex
> locale-dependent case folding.

Yes, I don't think anyone should be relying on case folding for aliases.
Not doing case folding also avoids locale problems with Turkic
languages.

Our mailmap also doesn't do case-folding for non-ASCII characters,
so there is some precedent, although I wish we were consistent by not
doing case folding at all.

> The main pain point would be making sure all platforms handle this nicely,
> esp since mac uses NFD and not NFC Unicode.

I don't think this affects command-line arguments, though, which are
just bytes.  Since running `git paramétrer` would just be passing
`paramétrer` as a command-line argument, then it should pass that value
as an unnormalized UTF-8 byte string.  It would only be normalized if
Git invoked `git-paramétrer` as a binary or script.

I don't think we have any Unicode normalization code at all in Git,
though, so if you want a quality implementation, that may be a thing we
need.

> Before implementing this, I'd like to hear:
> 
> 1. Is this a feature the project would like?

I think this would be useful.  I don't personally plan to use it, but I
can imagine a lot of other people would, and in general I'm in favour of
better i18n and l10n support.

> 2. Is my implementation approach reasonable?
> 3. What concerns should be addressed in said design?

As I said, Unicode normalization may be a thing you want to support
here.  Not having it isn't a complete dealbreaker, but it would prevent
hard-to-debug breakage.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA