git-p4 cloned repo contains mixed filename case -- how to fix?

I imported a large repo using git-p4, and discovered that I have some strangely mixed-case filenames, e.g.:

dirA/DIRb/file1.txt

and then other files like so:

DIRa/dirB/FILE2.txt

and so on. These get entered into the repo this way because git-p4 uses fast-import. This causes Git to mysteriously claim that there are untracked directories, which are definitely not untracked, and have no new files in them. I discovered from reading this question:

http://stackoverflow.com/questions/3446929/git-still-untracked-after-add

and specifically slayerIQ's answer, that this can be fixed by renaming the dirs in question to have the matching case. And indeed, in a few cases where files had only a single case format, this fixed it. But for the mixed up ones like I mentioned above, it does nothing. This sort of listing confirms my suspicions regarding the case:

git ls-tree --name-only -r branch

I've considered using history rewriting to try to fix it, but that seems awfully heavyweight and I'm a bit hesitant to go there unless I have to (the tree is ~25K files). On the other hand, I do "git status" on a clean tree and get a list of about 35 "untracked" paths. So it's sort of untenable.

I'm able to do a git-p4 clone from scratch if I need to, but I suspect the mixed case paths are coming from Perforce itself. SmartGit doesn't have this problem with the tree, and copying the exact tree to a new repo works fine (since it's added correctly).

Any ideas on how to proceed?

Thanks :)

View the original article here

`git-p4 clone` fails "new tip ... does not contain ..."

I'm runnining on Windows, with the windows p4 client, and git installed via Cygwin. The p4 client advertises how its syntax is regular across platforms and all that, so that should be hunky-dory.

So when I go to git-p4 clone --verbose //depot/path/to/source, it lists out all the files in the repository as though they were being checked out, then dies saying

Exception: fast-import failed: warning: Not updating refs/remotes/p4/master (new tip cd601b92da8625c90af05685e450e55b6d19c9e9 does not contain 3a512c9408e3cbeef 94c78dfd7115f81e4a6fd0d)

and concludes with a big block of "git-fast-import statistics". Looking at the error: new tip? Huh? What needs to contain it?

What I'm left with is a .git repo that's a couple of megs (much, much smaller than the full source tree would be). Any ideas?

View the original article here

git-p4 sync on different branch and repo

I'm trying to mirror a perforce repository, and git-p4 performs well enough on the main branch. I simply have to call git-p4 rebase. I'm also trying to mirror a different branch, but that's not working out so easily. I thought I could just do a git-p4 rebase --branch=p4/whatever //open/branches/whatever but rebase appears to ignore those tags, and if I do a sync instead I get the error message: fast-import failed: warning: Not updating refs/heads/p4/whatever (new tip 14f7e14e5079bb730363440901adee102e5f04c9 does not contain 0ca89b0333f408367e3676720b109a08cc40b3ae)

My initial import was a sync with @all, why wouldn't it be able to update, or is there a different/better way to do this?

View the original article here

git-p4 vs git-svn

My company currently uses SVN for it's repository. In order to get better merging and local branches/revisions I've been using git-svn over a subset of the larger repository. My company was recently purchased and one of the services offered by the corporate mothership is centralized SVN or Perforce hosting.

Given that neither Perforce or SVN offer the complete feature set I require I'm most likely going to continue to use git as the front end to whichever we choose. Is the user experience for git-p4 better than git-svn? Does git-p4 have suffient user base so that the client is up to date and bugs are fixed quickly?

This is a big repository, 100,000+ revisions which a very high branching factor and a non-standard layout. Does git-p4 suck less than git-svn for repositories of this scale? For example an initial fetch of the full SVN repository using git-svn has been running for over a month and it's only up to revision 60,000. Does this get any better when using Perforce as the back end?

And yes, going full native git is a possibility, but not a very likely one.

View the original article here