[email protected] 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
