The git-p4 bridge requires the p4 command line client properly set up. There is a lengthy tutorial on Perforce’s documentation website. The following is a short sums-up:
P4PORT=repo_url:repo_port P4USER=user_name P4PASSWD=password P4CLIENT=client_workspace_name P4EDITOR=vim
After you have done all these, don’t forget to issue “p4 sync repo_url” to test whether you are able to checkout stuff from your repository.
update 2014-02-25 git-p4 bridge has been moved to the top level git command. Use it as
git p4 instead of
The git-p4 bridge is a Python script to enable bidirectional operation between a Perforce depot and Git. It doesn’t come with the Git distribution by default. To make it invokable in your system, you need to download the script and put it into your system path. For me, I clone the Git source code from GitHub and make a soft-link to the script:
git clone https://github.com/git/git.git git_source_path
ln -s git_source_path/contrib/fast-import/git-p4 /usr/bin/git-p4
Windows users need to include the git-p4.bat file in the system path.
Four things to remember when using git-p4:
For the last one, the reason is that when you run “git merge”, Git creates an extra commit on top of the stack for the merging. This is not something we wanna show in the remote non-git repository. So we merge code with “git rebase”. Detailed explanation of the difference between git-merge and git-rebase goes here.
There is a detailed explanation on the usage of git-p4 in Git’s source. Here is an example almost covering daily usage:
git-p4 clone //depot/path/project
git commit changed_file
Normally we check in a .gitignore file to ignore files that we don’t want to check into the remote repository for each project. However, since the remote repository is not Git, it’s meaningless to check in this .gitignore file. To ignore this file, simply add an entry to .git/info/exclude.
There is no magic happening with git-p4. What it does is simply invoking the p4 command line tool to download sources to local, and then clone a Git repository out of it. You can simply verify this by typing “git branch -a”:
You may be amazed once again by how flexible the design of Git is which makes it possible to bridge to multiple VCS!
To quote Martin Fowler’s opinions on dual VCS, “a lot of teams can benefit from this dual-VCS working style, particularly if there’s a lot of corporate ceremony enforced by their corporate VCS. Using dual-VCS can often make both the local development team happier and the corporate controllers happier as their motivations for VCS are often different”.