aaron.dw...@imgtec.com wrote on Wed, 17 Jul 2013 22:11 +0000: > We recently have moved our project from Git to Perforce and those of us > who prefer Git still are using Git p4 to stay in Git land. One of the files > in our repository was renamed while still in Git, but the rename only > consisted of a case change of a character in the name. Now, on an OS X box > with a case insensitive file system (not sure if that matters), one of our > guys cloned from perforce with Git p4 and used @all to get all history. When > this operation is finished, the file name is in its original state, not the > newer renamed state.
So original file "Foo", new file "foo", to make it concrete. The "git p4 clone" command generates an internal .git/ history of the entire p4 repository, before checking out any files in the workspace. It does this without touching the filesystem, so I would expect it never to mangle case, even on OSX. You should be able to verify this with: mkdir test1 cd test1 git init git p4 clone --bare --destination . //depot/proj@all git ls-tree HEAD and see that "foo" is there, not "Foo". Then check that the rename really did happen: git log --stat --summary --follow -- foo should show a "rename Foo => foo" in there somewhere. Does this all work? I'd like to clear up this confusing part first. > Perforce doesn't respect that file as being in the repository. We > noticed this after making a local Git commit and upon issuing a Git p4 > submit, things go haywire with "file(s) not opened on this client" and > nothing getting submitted. Yep, it's all bad from there-on, I'm sure. I'm a bit out of my depth on case-insensitive file systems. Do check if the cloner in question has core.ignorecase config option set: git config --get core.ignorecase -- Pete -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html