From: "Torsten Bögershausen" <tboegi@web.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH/RFC] core.precomposeunicode is true by default
Date: Tue, 27 Aug 2013 17:06:35 +0200 [thread overview]
Message-ID: <521CC07B.4000504@web.de> (raw)
In-Reply-To: <xmqqvc2rfau9.fsf@gitster.dls.corp.google.com>
On 27.08.13 16:49, Junio C Hamano wrote:
> Torsten Bögershausen <tboegi@web.de> writes:
>
>>> ... see if that path can be seen under its alias. Why do we set it
>>> to "false"? Isn't this the true culprit?
>>>
>>> After all, this is not in the "reinit" codepath, so we know we are
>>> dealing with a repository that was created afresh.
>> There is nothing wrong with the auto-sensing as such.
>> The problem for many users today is that we set core.precomposeunicode
>> to false, when it should be true.
> I think we are in agreement then.
>
> The code detects a broken filesystem just fine, but what it does
> when it finds the filesystem is broken is wrong---it sets the
> variable to false. That makes the whole auto-sensing wrong, and I
> think it makes sense to correct that behaviour.
>
>> Let's look what precomposed_unicode does and go through a couple
>> of git operations.
>>
>> 1)
>> When we create a repo under Mac OS using HFS+,
>> we want to have precomposed_unicode = 1
> Yes.
>
>> 2)
>> When we access a repo from Windows/Linux using SAMBA,
> You mean s/repo/repository that resides on HFS+/?
Sorry being unclear here, trying being clearer with an example:
I have a /data/Docs on my linux box, which is handled by git
I export /data/Docs via SAMBA, and use the Finder under Mac OS to have it
mounted on my Mac OS X box:
//tb@Linux/Docs on /Volumes/Docs (smbfs, nodev, nosuid, mounted by tb)
>> readdir() will return decomposed.
>> When the repo is created by nonMacOS, core.precomposeunicode is undefined.
>> The precomposition is off, but should be on,
>> precomposed_unicode = -1, but should be = 1
> I do not think UTF-8-MAC is widely available; even if you flip the
> bit on, would it help much?
In the above example
/data/Docs/.git/config was created by Linux, so it does not have
core.precomposeunicode set, neither false nor true.
The Linux box does not have UTF-8-MAC under iconv,
but will ignore core.precomposeunicode anyway (since the code is not compiled here)
The Mac OS machine sees it under /Volumes/Docs/.git/config
And here we want the precomposition, even if core.precomposeunicode
is not present in the config.
next prev parent reply other threads:[~2013-08-27 15:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-27 1:21 [PATCH/RFC] core.precomposeunicode is true by default Torsten Bögershausen
2013-07-27 15:23 ` Duy Nguyen
2013-07-27 22:53 ` Torsten Bögershausen
2013-07-28 4:45 ` Duy Nguyen
2013-07-29 17:20 ` Junio C Hamano
2013-08-27 13:45 ` Torsten Bögershausen
2013-08-27 14:49 ` Junio C Hamano
2013-08-27 15:06 ` Torsten Bögershausen [this message]
2013-08-27 16:27 ` Junio C Hamano
2013-08-27 19:34 ` Torsten Bögershausen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=521CC07B.4000504@web.de \
--to=tboegi@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.