From: brian m. carlson Date: Sun, 08 Feb 2026 23:21:30 GMT Subject: Re: [RFC] Support UTF-8 characters in Git alias names Message-ID: In-Reply-To: <3124b359-2929-4f3f-9ac6-793277fe422b@jontes.page> 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