Perforce meets Git

Perforce is a Centralised Version Control System founded in 1995 and used by many companies. Git came into existence ten years later, in 2005. It revolutionized how we develop software and was adopted by the open-source community and many other organizations.

Depending on where you work and on which projects, your team may still use an old VCS like Perforce. Having used Git and knowing its power, you may encourage decision-makers in your company to switch to Git. But that can take some time.

Meanwhile, there is a tool that can help you bring the Git into your work environment and smoothen the transition to this newer Distributed Version Control System. It is called git-p4 and I will explain how it can help you and your team.

I am using Linux to demonstrate this. However, you should be able to run equivalent commands on Windows. First, we start by downloading the Helix Command-Line Client (P4). To do so, head to the Perforce website, and find the mentioned tool in the Download section. Choose the proper OS and get the download link. Run the following command with the link:

wget https://www.perforce.com/downloads/perforce/r23.2/bin.linux26x86_64/helix-core-server.tgz        

Extract it in a directory:

mkdir helix
tar -xvf helix-core-server.tgz -C helix/        

Then, we add a symbolic link to the p4 executable in our bin directory:

sudo ln -s /home/ubuntu/helix/p4 /usr/bin/p4        

Now, we should be able to get the following:

With that out of the way, it's time to get the git-p4 tool. It is a Python script and you can download it and set the right permissions with the following commands:

wget https://git.kernel.org/cgit/git/git.git/plain/git-p4.py
chmod +x git-p4.py        

Let's help Git in finding this script by setting up an alias to an external command:

git config --global alias.p4 '!python2 /home/ubuntu/helix/git-p4.py'        

You need Python2 to run the script. Yes, this old.

Finally, we have everything that we need. For the next step, we clone a publicly available Perforce repository into a local Git repository. Run the following command to set the right environment variables and clone the repo:

export P4PORT=public.perforce.com:1666
export P4USER=guest
git p4 clone //guest/perforce_software/jam@all p4import        

Run the following command:

git branch --all
git show HEAD
git log --pretty=format:"%C(Yellow)%h %C(Cyan)%ch %C(Green)%cn %C(White)%s" --graph -10        

Notice the p4 in remote branches. Also, there is a reference to the Perforce change-list in each commit message.

At this point, you can add a remote and push the Git repository to that and let the whole team know they can switch to Git workflow from now on. You can also keep the Perforce repository as a precaution.

If persuading everyone to switch to Git is not as easy as that, no worries. You can continue to work with Git, have your own local branches, commit to them, cherry-pick from them, and share patches with coworkers. But when it comes to publishing your work, you should maintain a linear history. That means you should rebase your local changes, and never rebase what you have pushed because Perforce keeps a linear history, and you cannot change what is submitted.

This is what a typical workflow looks like using this method. You commit some changes:

vim myfile
git add myfile
git status
git commit -m 'add my function'
git log --oneline --graph -5        

Sync your git repository with Perforce to get submitted changes by your coworkers:

git p4 sync        

Then rebase your work on that:

git p4 rebase        

Finally, submit your changes (if you have write access to that repository):

git p4 submit        

You can squash your commits into one by interactive rebasing. Also, the SHA1 of your commits will change after the push. Because git-p4 adds change-list numbers to the end of each commit message.

You can find sample code for Git workflows I have mentioned, and a lot more at my Dot Bash History repository. Looking forward to your contributions.