Migrating from Perforce to Git

For the past year I’ve been using Perforce for my VCS. Originally, I had used Perforce over something like Git or SVN because of its ubiquity in game development and its supposed advantage in handling large binary files. I think Perforce is a fine VCS, but the lack of documentation, being locked into using Perforce’s tools (at least to my knowledge), and an almost nonexistent community has me reconsidering other VCS options. I decided it was time to take another look at Git. Git is used basically everywhere, has a wealth of resources, and I like having the choice of different self-hosted services like GitLab and Gitea (which is what I’m using now). Git also seems to handle binary files better these days, with Git LFS adding file locking support, which basically allows Git users to get the same functionality that a Perforce checkout would enable.

With the decision to switch from Perforce to Git settled, I looked into how best to convert my existing Perforce depot into a Git repository. I wanted to write a quick help you avoid some of the snags I encountered.

If you don’t care about preserving your Perforce history

It should be noted, this process is extremely easy if you don’t care about preserving the history of your Perforce depot. If this applies to you, the easiest way to switch from Perforce to Git is to simply initialize a new Git repository in the local Perforce workspace. At this point you can add a .gitignore, initialize Git LFS, and then push this repo to the remote Git hosting service of your choice. This of course means your Git commit history will be starting from the latest revision Perforce depot you’ve pulled. This may be fine for projects early on in development, but if you have release milestones you’d like to be able to revert back to, you’ll want to preserve your history while converting to a Git repository. Luckily, Git provides some tools to assist in this conversion.

Covert from P4 to a Git while maintaining your Perforce history

Setting up the environment

We will need Python installed to run the git-p4 script. On Windows you can check to see if Python is installed by running

py --version

If Python is installed, you should see some output like

Python 3.10.1

Where the version number will be whatever is recent at the time reading this. In my case I was using 3.10.1. I have not tested this process using Python 2, but I don’t see why it wouldn’t work.

In my case, I was getting errors when trying to run this script. Downloading the latest script from here fixed the problem. In my case I’m using Fork, so my git-p4 script goes in the C:\Users\[USER_NAME]\AppData\Local\Fork\gitInstance\2.33.1\mingw64\libexec\git-core directory.

You’ll also need to add an alias to your .gitconfig, which aliases p4 to the git-p4.py script you just downloaded. The line should be added to [alias] section of your .gitconfig and should look something like this:

[alias]
	p4 = !'C:\\Users\\kevin\\AppData\\Local\\Fork\\gitInstance\\2.33.1\\mingw64\\libexec\\git-core\\git-p4.py'

You should replace the path with wherever you had downloaded the git-p4.py script in the previous step.

Cloning from your Perforce depot

You’ll first want to open your Perforce workspace. For me this meant opening P4V and connecting to my remote Perforce server. After that you can run:

git p4 clone //depot/main@all [Path_And_Name_Of_Your_New_Repository]

This will clone the Perforce depot as a Git repository in the path your specified. For example:

git p4 clone //depot/main@all /z/Repos/MyRepo

Will clone the repository in the folder Z:/Repos/MyRepo. The @all at the end of the depot path specifies to preserve the entire Perforce submission history as a Git commit history. Once the cloning completes, you can check this by running either git log or gitk. At this point you can do any other “smoke tests” you’d normally do to make sure your clone was successful.

Conclusion

At this point you have a new Git repository, and can do anything you’d do with any other Git repository. Since you’ve just cloned from Perforce, you’ll probably want to add a .gitignore, initialize Git LFS, add a .gitattributes file, and setup your new remote. At this point you can now use Git as your VCS for your project.

Welcome to my site 2.0!

It has been awhile since I utilized this site and made any posts. Needless to say a lot has changed in my life since 2019. I wanted to make a re-introduction post to explain what I’ve been up to recently and what’s new since I created this site.

Starting a game company

My “side hustle” is no longer trying to start a game company, at least right now. At some point after making that original introduction post, I realized I enjoyed game development much more when I treated it purely as a hobby in my free time. I like being able to focus on making what I want at the pace I want. By treating gamedev as just a hobby, I can make fan games or small standalone demos since I don’t have to worry about marketability or anything like that.

I still want to release an original game of my own one day, but I’m less interested in making a career out of game development. If I happen to eventually release something that sells enough or gets enough support to sustain me full-time, then that’s great, but it is no longer the end goal. For now, I just want to work on improving my skills and getting game projects out into the world for people to play.

Engine development

I am also no longer trying to learn OpenGL and make a game engine from scratch. In the same way I realized I enjoy game development as a hobby rather than a “side hustle,” I realized I enjoy designing and implementing gameplay systems and levels more than I’m interested in making a game engine. Since the beginning of 2020, I’ve been using Unreal Engine 4 and have been enjoying its workflow. I’ve since made a couple game projects in it, to varying levels of completeness. I may revisit some of those unfinished projects in a future post.

What’s next?

My main goal for this year is to release more game projects. There are a couple fan game projects I have in mind and I want to release betas for them by the end of this year. Another goal of mine is to be more active with this site. My main focus for the site will be making tutorials and writing technical articles about game development problems I faced and how I solved them. I think within the Unreal Engine community, we’re lacking in community-made resources compared to other engines like Unity and Godot. I’m a big proponent of knowledge sharing, and want to make sure there are high quality guides out there for Unreal Engine.

New site features

I’ve started to add more pages to the site aside from blog posts. Along with the site, I’ve also set up a self-hosted Git service for my game projects and libraries. You can find that under the “Portfolio” tab at the top of the page. You can also find links to my GitLab and GitHub under that same tab as well.

Like always, I hope you enjoy your stay! Stay tuned for more blog posts in the near future.