Re: Feature request: better error messages when UTF-8 bites

["Torsten Bögershausen" <tboegi@web.de>]

[]

>
> BTW you actually raise another issue - I do think for file paths git could
> either recompose (NFC) or decompose (NFD) the strings on storage and
> comparison (which should probably be an option... the current default for
> 2.30.2 is to treat them and print them as binary (escaped on print).
> Consider the following when using core.quotePath=false:
>
> $ touch "nfc_$(printf '\xf4')"

This is not valid unicode, isn't it ?
Probably we need to use the octal version, since not all
printf() implementation support hex values starting with 0x,
but all of them support octal:

auml=$(printf '\303\244')
aumlcdiar=$(printf '\141\314\210')


> $ touch "nfd_$(printf '\x6f\xcc\x82')"
> $ git add nf[cd]*
> $ git status
> On branch test
> Changes to be committed:
>   (use "git restore --staged <file>..." to unstage)
>     new file:   nfc_ô
>     new file:   nfd_ô

>
> I'm not sure how the Unicode will be translated here, it might depend on the
> mail client if they even's get sent as-is, but both shows the exact same
> file name, one in NFD and one in NFC format.

Translated by "whom" ?
Most programs do no translate anything here.
>
> Both are canonically equivalent and reversible. It appears MacOS already
> decompose (NFD?) filenames by default and git provides an option to
> recompose the characters (core.precomposeUnicode) which, according to the
> manual, is not even usable on Linux...

Yes. Technically you can have both under Linux, at least unless you
are running ZFS, which may be created unicode-aware (or not, that is the default).

But why do you want to have 2 files on disk with different normalizations ?


>
> More on Unicode normalization: https://unicode.org/reports/tr15/
>
> --
> Thomas