On Fri, Sep 14, 2012 at 9:48 AM, Andreas Ericsson <ae@xxxxxx> wrote: > On 09/14/2012 02:37 PM, Larry Martell wrote: >> On Thu, Sep 13, 2012 at 5:24 PM, Larry Martell <larry.martell@xxxxxxxxx> 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! -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html