threads / discuss / 46382

Re: Git on macOS shows committed files as untracked

Subject: Re: Git on macOS shows committed files as untracked

## tl;dr

6 messages between Jul 14, 2017 and Jul 14, 2017.

replies: 5people: 5as markdown or json

Lutz Roeder· Jul 14, 2017, 04:51 UTC · lore
Using precomposeunicode still reproduces the issue:
Repro steps:
1. Download https://www.dropbox.com/s/0q5pbpqpckwzj7b/gitstatusrepro.zip?dl=0
2. unzip gitstatusrepro.zip && cd gitstatusrepro
3. git reset --hard
4. git -c core.precomposeunicode=true status
On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)
"d\314\207\316\271\314\223\314\200\342\225\223\316\265\357\256\257\360\222\221\217\342\227\213\342\225\223\320\243\314\213/"
nothing added to commit but untracked files present (use "git add" to track)
Show 11 quoted lines
> From: Torsten Bögershausen <tboegi@web.de>
>
> Thanks for the fast analyzes -
> in short:
> what does
> git -c core.precomposeunicode=true status
> say ?
>
>
> The easiest thing may be to set
> git config --global core.precomposeunicode true
Torsten Bögershausen· Jul 14, 2017, 08:41 UTC · lore
On 14/07/17 06:49, Lutz Roeder wrote:
Show 12 quoted lines
> Using precomposeunicode still reproduces the issue:
> 
> Repro steps:
> 
> 1. Download https://www.dropbox.com/s/0q5pbpqpckwzj7b/gitstatusrepro.zip?dl=0
> 2. unzip gitstatusrepro.zip && cd gitstatusrepro
> 3. git reset --hard
> 4. git -c core.precomposeunicode=true status
> 
> On branch master
> Untracked files:
>    (use "git add <file>..." to include in what will be committed)

A (short) investigation shows that this seems to be invalid unicode, at least from a MacOSX point of view ?

Unzipping your repo shows this:
  git status -u
   deleted: 
"\341\270\213\341\274\262\342\225\223\316\265\357\256\257\360\222\221\217\342\227\213\342\225\223\323\262/test.txt" 
===============
If I run this:
  xx=$(printf 
"d\314\207\316\271\314\223\314\200\342\225\223\316\265\357\256\257\360\222\221\217\342\227\213\342\225\223\320\243\314\213/")
echo   $xx | iconv -f UTF-8-MAC -t UTF-16 | xxd

iconv: (stdin):1:5: cannot convert 0000000: feff 1e0b 1f32 2553 03b5 fbaf .....2%S.... =============================== So I don't know if we can do something in Git to improve your repo. How did you end up with such a directory name ? And would it be possible to rename it ?

Elliot Chandler· Jul 14, 2017, 09:46 UTC · re: Torsten Bögershausen · lore

For what it's worth, the file looks normal in Gentoo GNU/Linux (name appears "ḋἲ╓εﮯ𒑏○╓Ӳ" and it seems to work like any other directory).

On Fri, Jul 14, 2017 at 4:41 AM, Torsten Bögershausen <tboegi@web.de> wrote:
Show 42 quoted lines
>
>
> On 14/07/17 06:49, Lutz Roeder wrote:
>>
>> Using precomposeunicode still reproduces the issue:
>>
>> Repro steps:
>>
>> 1. Download
>> https://www.dropbox.com/s/0q5pbpqpckwzj7b/gitstatusrepro.zip?dl=0
>> 2. unzip gitstatusrepro.zip && cd gitstatusrepro
>> 3. git reset --hard
>> 4. git -c core.precomposeunicode=true status
>>
>> On branch master
>> Untracked files:
>>    (use "git add <file>..." to include in what will be committed)
>
>
> A (short) investigation shows that this seems to be invalid unicode,
> at least from a MacOSX point of view ?
>
> Unzipping your repo shows this:
>  git status -u
>   deleted:
> "\341\270\213\341\274\262\342\225\223\316\265\357\256\257\360\222\221\217\342\227\213\342\225\223\323\262/test.txt"
>
> ===============
> If I run this:
>  xx=$(printf
> "d\314\207\316\271\314\223\314\200\342\225\223\316\265\357\256\257\360\222\221\217\342\227\213\342\225\223\320\243\314\213/")
>
> echo   $xx | iconv -f UTF-8-MAC -t UTF-16 | xxd
>
> iconv: (stdin):1:5: cannot convert
> 0000000: feff 1e0b 1f32 2553 03b5 fbaf            .....2%S....
> ===============================
> So I don't know if we can do something in Git to improve your repo.
> How did  you end up with such a directory name ?
> And would it be possible to rename it ?
>
>
Torsten Bögershausen· Jul 14, 2017, 12:35 UTC · lore

(Please no top-posting) On 14/07/17 11:45, Elliot Chandler wrote:

> For what it's worth, the file looks normal in Gentoo GNU/Linux (name appears 
> "ḋἲ╓εﮯ𒑏○╓Ӳ" and it seems to work like any other directory).
> 

Thanks for testing - Normal and Normal ;-) For me the 6th code point does look strange The "box" with 04142F: Code point 4142F is unassigned and is outside any currently defined block range.

So this is not valid Unicode, so we have a problem here under MacOS - not much Git can do about it.

Show 48 quoted lines
> On Fri, Jul 14, 2017 at 4:41 AM, Torsten Bögershausen <tboegi@web.de 
> <mailto:tboegi@web.de>> wrote:
> 
> 
> 
>     On 14/07/17 06:49, Lutz Roeder wrote:
> 
>         Using precomposeunicode still reproduces the issue:
> 
>         Repro steps:
> 
>         1. Download
>         https://www.dropbox.com/s/0q5pbpqpckwzj7b/gitstatusrepro.zip?dl=0
>         <https://www.dropbox.com/s/0q5pbpqpckwzj7b/gitstatusrepro.zip?dl=0>
>         2. unzip gitstatusrepro.zip && cd gitstatusrepro
>         3. git reset --hard
>         4. git -c core.precomposeunicode=true status
> 
>         On branch master
>         Untracked files:
>             (use "git add <file>..." to include in what will be committed)
> 
> 
>     A (short) investigation shows that this seems to be invalid unicode,
>     at least from a MacOSX point of view ?
> 
>     Unzipping your repo shows this:
>       git status -u
>        deleted:
>     "\341\270\213\341\274\262\342\225\223\316\265\357\256\257\360\222\221\217\342\227\213\342\225\223\323\262/test.txt"
> 
> 
>     ===============
>     If I run this:
>       xx=$(printf
>     "d\314\207\316\271\314\223\314\200\342\225\223\316\265\357\256\257\360\222\221\217\342\227\213\342\225\223\320\243\314\213/")
> 
>     echo   $xx | iconv -f UTF-8-MAC -t UTF-16 | xxd
> 
>     iconv: (stdin):1:5: cannot convert
>     0000000: feff 1e0b 1f32 2553 03b5 fbaf            .....2%S....
>     ===============================
>     So I don't know if we can do something in Git to improve your repo.
>     How did  you end up with such a directory name ?
>     And would it be possible to rename it ?
> 
> 
> 
Jeff King· Jul 14, 2017, 13:28 UTC · re: Torsten Bögershausen · lore
On Fri, Jul 14, 2017 at 02:35:52PM +0200, Torsten Bögershausen wrote:
Show 10 quoted lines
> (Please no top-posting)
> On 14/07/17 11:45, Elliot Chandler wrote:
> > For what it's worth, the file looks normal in Gentoo GNU/Linux (name
> > appears "ḋἲ╓εﮯ𒑏○╓Ӳ" and it seems to work like any other directory).
> > 
> Thanks for testing -
> Normal and Normal ;-)
> For me the 6th code point does look strange
> The "box" with 04142F:
> Code point 4142F is unassigned and is outside any currently defined block range.

Are you sure? I get u+1244f. I don't have a glyph for it in my font, but at least it's a real unicode codepoint (cuneiform 1).

> So this is not valid Unicode, so we have a problem here under MacOS -
> not much Git can do about it.

I do still suspect this is the root of the problem. There's something about the string that HFS+ doesn't want to store, and there's nothing we can do to fix that.

-Peff
Andreas Schwab· Jul 14, 2017, 13:29 UTC · re: Torsten Bögershausen · lore
On Jul 14 2017, Torsten Bögershausen <tboegi@web.de> wrote:
Show 9 quoted lines
> (Please no top-posting)
> On 14/07/17 11:45, Elliot Chandler wrote:
>> For what it's worth, the file looks normal in Gentoo GNU/Linux (name
>> appears "ḋἲ╓εﮯ𒑏○╓Ӳ" and it seems to work like any other directory).
>>
> Thanks for testing -
> Normal and Normal ;-)
> For me the 6th code point does look strange
> The "box" with 04142F:
This is actually 1244f (CUNEIFORM NUMERIC SIGN ONE BAN2).
Andreas.
-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

← back to recent threads