* Bug in git-status with non-ascii characters:
@ 2007-01-09 5:09 Brian Gernhardt
2007-01-09 5:28 ` Shawn O. Pearce
2007-01-09 5:39 ` Juergen Ruehle
0 siblings, 2 replies; 6+ messages in thread
From: Brian Gernhardt @ 2007-01-09 5:09 UTC (permalink / raw)
To: Git Mailing List
`git status` always reports the following:
----- 8< -----
# On branch refs/heads/master
# Untracked files:
# (use "git add <file>..." to incrementally add content to commit)
#
# gitweb/test/Märchen
no changes added to commit (use "git add" and/or "git commit [-a|-i|-
o]")
----- 8< -----
When I do `rm gitweb/test/M<tab>` to remove this apparently unneeded
file, `git status` reports:
----- 8< -----
# On branch refs/heads/master
# Changed but not added:
# (use "git add <file>..." to incrementally add content to commit)
#
# deleted: gitweb/test/Märchen
#
no changes added to commit (use "git add" and/or "git commit [-a|-i|-
o]")
----- 8< -----
This is on Mac OS X, file system is HFS+ (Journaled). Is this
expected? I can't figure out why it's happening.
~~ Brian
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bug in git-status with non-ascii characters:
2007-01-09 5:09 Bug in git-status with non-ascii characters: Brian Gernhardt
@ 2007-01-09 5:28 ` Shawn O. Pearce
2007-01-09 5:35 ` Brian Gernhardt
2007-01-09 5:39 ` Juergen Ruehle
1 sibling, 1 reply; 6+ messages in thread
From: Shawn O. Pearce @ 2007-01-09 5:28 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git Mailing List
Brian Gernhardt <benji@silverinsanity.com> wrote:
> This is on Mac OS X, file system is HFS+ (Journaled). Is this
> expected? I can't figure out why it's happening.
There's a bug in the Mac OS X filesystem apparently.
Git created the file with one encoding. Later when Git does a
readdir() to find out what files are in the directory Mac OS X is
returning it with a different encoding. There's more details in
the list archives; all I know is Mac OS X is broken here. And we
Mac users get to suffer...
P.S. I'm also a Mac OS X user. I've gotten used to that file
showing up and just visually ignore it now. *sigh*
--
Shawn.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bug in git-status with non-ascii characters:
2007-01-09 5:28 ` Shawn O. Pearce
@ 2007-01-09 5:35 ` Brian Gernhardt
0 siblings, 0 replies; 6+ messages in thread
From: Brian Gernhardt @ 2007-01-09 5:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List
On Jan 9, 2007, at 12:28 AM, Shawn O. Pearce wrote:
> There's a bug in the Mac OS X filesystem apparently.
>
> Git created the file with one encoding. Later when Git does a
> readdir() to find out what files are in the directory Mac OS X is
> returning it with a different encoding. There's more details in
> the list archives; all I know is Mac OS X is broken here. And we
> Mac users get to suffer...
D'oh. RTFL? I should have known better minds than I had looked at
this already.
> P.S. I'm also a Mac OS X user. I've gotten used to that file
> showing up and just visually ignore it now. *sigh*
I'm pretty used to it showing up, I was just poking around git (see
recent patches) and thought about tracking it down.
~~ Brian
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bug in git-status with non-ascii characters:
2007-01-09 5:09 Bug in git-status with non-ascii characters: Brian Gernhardt
2007-01-09 5:28 ` Shawn O. Pearce
@ 2007-01-09 5:39 ` Juergen Ruehle
2007-01-09 14:14 ` Wolfgang Fischer
1 sibling, 1 reply; 6+ messages in thread
From: Juergen Ruehle @ 2007-01-09 5:39 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git Mailing List
Brian Gernhardt writes:
> `git status` always reports the following:
>
> ----- 8< -----
> # On branch refs/heads/master
> # Untracked files:
> # (use "git add <file>..." to incrementally add content to commit)
> #
> # gitweb/test/Märchen
> no changes added to commit (use "git add" and/or "git commit [-a|-i|-
> o]")
> ----- 8< -----
>
> When I do `rm gitweb/test/M<tab>` to remove this apparently unneeded
> file, `git status` reports:
>
> ----- 8< -----
> # On branch refs/heads/master
> # Changed but not added:
> # (use "git add <file>..." to incrementally add content to commit)
> #
> # deleted: gitweb/test/Märchen
> #
> no changes added to commit (use "git add" and/or "git commit [-a|-i|-
> o]")
> ----- 8< -----
>
> This is on Mac OS X, file system is HFS+ (Journaled). Is this
> expected? I can't figure out why it's happening.
It's a known problem with HFS+: it uses different byte sequences to
identify the same file. Therefore git finds gitweb/test/Märchen
unchanged but also a gitweb/test/Märchen in the working directory
using a different byte sequence for the name as reported in status. If
you delete the file git doesn't find the file any longer and reports
that in status as well.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bug in git-status with non-ascii characters:
2007-01-09 5:39 ` Juergen Ruehle
@ 2007-01-09 14:14 ` Wolfgang Fischer
2007-01-09 14:48 ` Johannes Schindelin
0 siblings, 1 reply; 6+ messages in thread
From: Wolfgang Fischer @ 2007-01-09 14:14 UTC (permalink / raw)
To: Git Mailing List; +Cc: Brian Gernhardt, Juergen Ruehle
On 09.01.2007, at 06:39, Juergen Ruehle wrote:
> Brian Gernhardt writes:
>> `git status` always reports the following:
>>
>> ----- 8< -----
>> # On branch refs/heads/master
>> # Untracked files:
>> # (use "git add <file>..." to incrementally add content to commit)
>> #
>> # gitweb/test/Märchen
>> no changes added to commit (use "git add" and/or "git commit [-a|-i|-
>> o]")
>> ----- 8< -----
>>
>> When I do `rm gitweb/test/M<tab>` to remove this apparently unneeded
>> file, `git status` reports:
>>
>> ----- 8< -----
>> # On branch refs/heads/master
>> # Changed but not added:
>> # (use "git add <file>..." to incrementally add content to commit)
>> #
>> # deleted: gitweb/test/Märchen
>> #
>> no changes added to commit (use "git add" and/or "git commit [-a|-i|-
>> o]")
>> ----- 8< -----
>>
>> This is on Mac OS X, file system is HFS+ (Journaled). Is this
>> expected? I can't figure out why it's happening.
>
> It's a known problem with HFS+: it uses different byte sequences to
> identify the same file. Therefore git finds gitweb/test/Märchen
> unchanged but also a gitweb/test/Märchen in the working directory
> using a different byte sequence for the name as reported in status. If
> you delete the file git doesn't find the file any longer and reports
> that in status as well.
Since this problem is discussed every other week, how about changing
the name of the test file to scheußlicher_Dateiname or so, since the
sz-ligature does not have the problem of different UTF-8
normalization forms. It wont fix HFS+, but since HFS+ is designed to
accept either UTF-8 normalization form and returning just NFD, nobody
will change/fix HFS+ anyway.
Wolfgang
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bug in git-status with non-ascii characters:
2007-01-09 14:14 ` Wolfgang Fischer
@ 2007-01-09 14:48 ` Johannes Schindelin
0 siblings, 0 replies; 6+ messages in thread
From: Johannes Schindelin @ 2007-01-09 14:48 UTC (permalink / raw)
To: Wolfgang Fischer; +Cc: Git Mailing List, Brian Gernhardt, Juergen Ruehle
[-- Attachment #1: Type: TEXT/PLAIN, Size: 342 bytes --]
Hi,
On Tue, 9 Jan 2007, Wolfgang Fischer wrote:
> Since this problem is discussed every other week, how about changing the
> name of the test file to scheußlicher_Dateiname or so, since the
> sz-ligature does not have the problem of different UTF-8 normalization
> forms.
Good idea! But I'd name it "Oane-Maß" instead ;-)
Ciao,
Dscho
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2007-01-09 14:48 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-01-09 5:09 Bug in git-status with non-ascii characters: Brian Gernhardt
2007-01-09 5:28 ` Shawn O. Pearce
2007-01-09 5:35 ` Brian Gernhardt
2007-01-09 5:39 ` Juergen Ruehle
2007-01-09 14:14 ` Wolfgang Fischer
2007-01-09 14:48 ` Johannes Schindelin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox