Re: [RFC] i18n.pathencoding

From: Torsten Bögershausen <tboegi@web.de>
Date: Sep 8, 2012, 10:09 UTC
Message-ID: <504B194A.6050009@web.de>
In-Reply-To: <5043E4B4.9050801@dewire.com>

On 03.09.12 00:59, Robin Rosenberg wrote:

Show 18 quoted lines

> Torsten Bögershausen skrev 2012-09-01 08.11:> Allow path names to be encoded in UTF-8 in the repository
>> and checkout out as e.g. ISO-8859-1 in the working tree.
> 
> Ack for attempting this.
> 
> Did it myself if 2007, but times weren't ripe then, I guess.
> 
>> +i18n.pathEncoding::
>> +    This option is only used by some implementations of git.
>> +    When "git init" sets core.supportspathencoding to true,
>> +    i18n.pathEncoding can be set to re-encode path names when
>> +    a working tree is checked out.
>> +    Path names may be e.g. encoded in ISO-8859-1 and are stored as
>> +    UTF-8 encoded in the repository.
>> +    When not set, the encoding of path names is the same in working tree
>> +    and the repository.
> 
> "If set, then core.precomposeunicode is ignored on Mac OS X."

Thanks for comments, I will integrate them (but don't expect that too soon ;-).

Before that I want to find & fix the performance issues, and the t1450 breakage asks for my attention again.

However, the combination of i18n.pathEncoding and core.precomposeunicode under Mac OS X needs to be clarified. Mac OS X only allows unicode (an "Ä" encoded in ISO-8859-1 gives a single byte), and the HFS+ filesystem will list it as %C4.

So the i18.pathencoding does not make sence under Mac OS X, and should be ignored. It is not ignored today, since the characters use in t3911 are choosen to be both valid UTF-8 and ISO-8859-1 code points/characters, so that the feature can be tested on Mac OS X.