inconsistent behavior on mac with case changes

inconsistent behavior on mac with case changes

[Larry Martell]

I created a dir on my Mac called Rollup, and pushed it out. Then went
to a CentOS box, pulled it, and realized I wanted to call it RollUp
(capital U). I renamed it, and pushed out the change. Went back to the
Mac and did a pull - it said it created the RollUp dir, but it did not
- it was still called Rollup. I reamed it, but status did not pick up
the change. Then I checked out a branch that had Rollup, but it was
gone there - no Rollup or RollUp. I did a merge and then RollUp was
created.

I know the Mac is somewhat inconsistent with how it deals with case, e.g.:

$ ls
RollUp
$ ls -d Rollup
Rollup
$ ls -d RollUp
RollUp
$ find . -name Rollup -print
$ find . -name RollUp -print
./RollUp

So I guess I can understand git also being inconsistent there. But
what really got me was the dir being gone on the branch.

Is all this expected behavior?

-larry

Re: inconsistent behavior on mac with case changes

[Larry Martell]

On Thu, Sep 13, 2012 at 5:24 PM, Larry Martell <larry.martell@gmail.com> wrote:
> I created a dir on my Mac called Rollup, and pushed it out. Then went
> to a CentOS box, pulled it, and realized I wanted to call it RollUp
> (capital U). I renamed it, and pushed out the change. Went back to the
> Mac and did a pull - it said it created the RollUp dir, but it did not
> - it was still called Rollup. I reamed it, but status did not pick up
> the change. Then I checked out a branch that had Rollup, but it was
> gone there - no Rollup or RollUp. I did a merge and then RollUp was
> created.
>
> I know the Mac is somewhat inconsistent with how it deals with case, e.g.:
>
> $ ls
> RollUp
> $ ls -d Rollup
> Rollup
> $ ls -d RollUp
> RollUp
> $ find . -name Rollup -print
> $ find . -name RollUp -print
> ./RollUp
>
> So I guess I can understand git also being inconsistent there. But
> what really got me was the dir being gone on the branch.
>
> Is all this expected behavior?

Is this not the correct list for a question like this? If not, is
there another list that's more appropriate?

Re: inconsistent behavior on mac with case changes

[Andreas Ericsson]

On 09/14/2012 02:37 PM, Larry Martell wrote:
> On Thu, Sep 13, 2012 at 5:24 PM, Larry Martell <larry.martell@gmail.com> wrote:
>> I created a dir on my Mac called Rollup, and pushed it out. Then went
>> to a CentOS box, pulled it, and realized I wanted to call it RollUp
>> (capital U). I renamed it, and pushed out the change. Went back to the
>> Mac and did a pull - it said it created the RollUp dir, but it did not
>> - it was still called Rollup. I reamed it, but status did not pick up
>> the change. Then I checked out a branch that had Rollup, but it was
>> gone there - no Rollup or RollUp. I did a merge and then RollUp was
>> created.
>>
>> I know the Mac is somewhat inconsistent with how it deals with case, e.g.:
>>
>> $ ls
>> RollUp
>> $ ls -d Rollup
>> Rollup
>> $ ls -d RollUp
>> RollUp
>> $ find . -name Rollup -print
>> $ find . -name RollUp -print
>> ./RollUp
>>
>> So I guess I can understand git also being inconsistent there. But
>> what really got me was the dir being gone on the branch.
>>
>> Is all this expected behavior?
> 

More or less. Git sees Rollup and RollUp as two different directories,
so assuming everything inside it is committed git is free to remove
the directory that exists on one branch but not the other when switching
branches in order to keep the work tree in sync with the index.

Consider this (most output cut away):

git init
touch base; git add base git commit -m "first commit"
mkdir foo && touch foo/lala && git add foo/lala && git commit -m "meh"
git checkout -b newbranch HEAD^
ls -ld foo
ls: cannot access foo.: No such file or directory
mkdir bar && touch bar/bear && git add bar/bear && git commit -m "rawr"
git checkout master
ls -ld bar
ls: cannot access bar.: no such file or directory

If git would leave your committed directory in the worktree when you
move to a branch that doesn't have it, it would put you in a very
weird position where you may have to clear away rubble from someone
else, or start depending on code that's not in your branch. So yes,
you're seeing the expected behaviour, and OSX is retarded wrt case
sensitive filenames. I'd suggest you either reformat your drive to
stop using HFS+ or do your development work inside a loopback fs
mounted with proper case sensitivity, as there's really no sane way
around the problem OSX causes.

> Is this not the correct list for a question like this? If not, is
> there another list that's more appropriate?

It is, but people don't always spend their days looking for questions
to answer.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: inconsistent behavior on mac with case changes

[Larry Martell]

On Fri, Sep 14, 2012 at 9:48 AM, Andreas Ericsson <ae@op5.se> wrote:
> On 09/14/2012 02:37 PM, Larry Martell wrote:
>> On Thu, Sep 13, 2012 at 5:24 PM, Larry Martell <larry.martell@gmail.com> wrote:
>>> I created a dir on my Mac called Rollup, and pushed it out. Then went
>>> to a CentOS box, pulled it, and realized I wanted to call it RollUp
>>> (capital U). I renamed it, and pushed out the change. Went back to the
>>> Mac and did a pull - it said it created the RollUp dir, but it did not
>>> - it was still called Rollup. I reamed it, but status did not pick up
>>> the change. Then I checked out a branch that had Rollup, but it was
>>> gone there - no Rollup or RollUp. I did a merge and then RollUp was
>>> created.
>>>
>>> I know the Mac is somewhat inconsistent with how it deals with case, e.g.:
>>>
>>> $ ls
>>> RollUp
>>> $ ls -d Rollup
>>> Rollup
>>> $ ls -d RollUp
>>> RollUp
>>> $ find . -name Rollup -print
>>> $ find . -name RollUp -print
>>> ./RollUp
>>>
>>> So I guess I can understand git also being inconsistent there. But
>>> what really got me was the dir being gone on the branch.
>>>
>>> Is all this expected behavior?
>>
>
> More or less. Git sees Rollup and RollUp as two different directories,
> so assuming everything inside it is committed git is free to remove
> the directory that exists on one branch but not the other when switching
> branches in order to keep the work tree in sync with the index.
>
> Consider this (most output cut away):
>
> git init
> touch base; git add base git commit -m "first commit"
> mkdir foo && touch foo/lala && git add foo/lala && git commit -m "meh"
> git checkout -b newbranch HEAD^
> ls -ld foo
> ls: cannot access foo.: No such file or directory
> mkdir bar && touch bar/bear && git add bar/bear && git commit -m "rawr"
> git checkout master
> ls -ld bar
> ls: cannot access bar.: no such file or directory
>
> If git would leave your committed directory in the worktree when you
> move to a branch that doesn't have it, it would put you in a very
> weird position where you may have to clear away rubble from someone
> else, or start depending on code that's not in your branch. So yes,
> you're seeing the expected behaviour, and OSX is retarded wrt case
> sensitive filenames. I'd suggest you either reformat your drive to
> stop using HFS+ or do your development work inside a loopback fs
> mounted with proper case sensitivity, as there's really no sane way
> around the problem OSX causes.

Thanks for the detailed reply!