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

From: Jonatan Holmgren <jonatan@jontes.page>
Date: Feb 9, 2026, 15:19 UTC
Message-ID: <c3445fa2-a217-4e48-b0d0-ad41a563c6c4@jontes.page>
In-Reply-To: <xmqqikc66k5k.fsf@gitster.g>

Thanks for chiming in!

 > Isn't NKC/NKD a macOS-only issue in practice?  Anything on the
 > command line "git" potty and "git-blah" built-in commands receive
 > goes through precompose_argv_prefix() to be normalized on that
 > platform.

If we use Jeff's proposed alias.*.{keyname} approach with literal byte matching macOS should already handle the normalization at the argv level before Git even sees it, correct? I'm not very familiar with how macOS handles this.

 > I am not fundamentally against this, as long as such an addition
 > does not introduce unnecessary bugs and ambiguities.  IOW, do not
 > force me to read bug reports in this area after it is done.

Understood. Jeff's subsection approach seems safest, it uses existing config infrastructure that already supports arbitrary bytes in subsections. This would enable

     [alias "förgrena"]
         command = branch

as an alternative to (not a replacement for) the current ASCII-only:

     [alias]
         forgrena = branch

Is this sound?

Jonatan

On 2026-02-09 15:55, Junio C Hamano wrote:

Show 27 quoted lines

> "brian m. carlson"<sandals@crustytoothpaste.net> writes:
> 
>> 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.
> Isn't NKC/NKD a macOS-only issue in practice?  Anything on the
> command line "git" potty and "git-blah" built-in commands receive
> goes through precompose_argv_prefix() to be normalized on that
> platform.
> 
>>> 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.
> I am not fundamentally against this, as long as such an addition
> does not introduce unnecessary bugs and ambiguities.  IOW, do not
> force me to read bug reports in this area after it is done.
> 
>>> 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.
> A buggy normalization implementation would be also a source of
> unnecessary bugs.  We cannot have and eat that cake so easily 😉.