{"thread":{"id":"34460","subject":"Git-P4 Bug With Filename Case Change","startedAt":"2013-07-17T22:11:45Z","lastAt":"2013-07-20T13:34:18Z","messageCount":2,"participants":["Aaron Dwyer","Pete Wyckoff"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"223619","messageId":"897B3B32-0200-4290-AA16-DCAF42923CE0@imgtec.com","threadId":"34460","inReplyTo":null,"subject":"Git-P4 Bug With Filename Case Change","fromName":"Aaron Dwyer","fromEmail":"aaron.dwyer@imgtec.com","sentAt":"2013-07-17T22:11:45Z","receivedAt":"2013-07-17T22:11:45Z","isPatch":false,"sender":{"key":"aaron.dwyer@imgtec.com","avatar":null},"body":"Hello Git Developers,\n\n\tWe 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.  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.\n\nAaron Dwyer\nSenior Software Architect\nImagination Technologies\n"},{"id":"223847","messageId":"20130720133418.GA18479@padd.com","threadId":"34460","inReplyTo":"897B3B32-0200-4290-AA16-DCAF42923CE0@imgtec.com","subject":"Re: Git-P4 Bug With Filename Case Change","fromName":"Pete Wyckoff","fromEmail":"pw@padd.com","sentAt":"2013-07-20T13:34:18Z","receivedAt":"2013-07-20T13:34:18Z","isPatch":false,"sender":{"key":"pw@padd.com","avatar":null},"body":"Aaron.Dwyer@imgtec.com wrote on Wed, 17 Jul 2013 22:11 +0000:\n> \tWe 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.\n\nSo original file \"Foo\", new file \"foo\", to make it concrete.\n\nThe \"git p4 clone\" command generates an internal .git/ history of\nthe entire p4 repository, before checking out any files in the\nworkspace.  It does this without touching the filesystem, so I\nwould expect it never to mangle case, even on OSX.\n\nYou should be able to verify this with:\n\n    mkdir test1\n    cd test1\n    git init\n    git p4 clone --bare --destination . //depot/proj@all\n\n    git ls-tree HEAD\n\nand see that \"foo\" is there, not \"Foo\".\n\nThen check that the rename really did happen:\n\n    git log --stat --summary --follow -- foo\n\nshould show a \"rename Foo => foo\" in there somewhere.\n\nDoes this all work?  I'd like to clear up this confusing part\nfirst.\n\n> \tPerforce 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.\n\nYep, it's all bad from there-on, I'm sure.\n\nI'm a bit out of my depth on case-insensitive file systems.  Do\ncheck if the cloner in question has core.ignorecase config option\nset:\n\n    git config --get core.ignorecase\n\n\n\t\t-- Pete\n"}]}