Re: inconsistent behavior on mac with case changes

> 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.