by James Creasy
"Use the right tool for the job." my father would say, as he hammered a screwdriver into a rusted set of brake drums.
Of course, if you don't have a chisel, you make do with what you have at hand. But when a tool better suited for the task at hand comes along, you are smart to start using it.
Git burst onto the SCM scene in exactly this role- packing not merely one better tool, but a whole bag. For those developers able and willing to master Git's arcane logic, fast and private branching, easy context switching, speed from running purely local operations on full local history, and a flexible and powerful command set became some of Git's sweetest come-hither features.
Need to stop work on a big feature to fix a critical bug in a release? No problem; switch over to a new branch, fix the bug, and switch right back to your longer-term work. Need to pull just some of your work out of one development branch and into another? Cherry-pick, use a patch, or rebase. For many developers, Git's features make it easy to perform these tasks. Git helps you do your job. Git makes you a better developer. It's an easy next step to conclude Git is the perfect SCM!
Not so fast! SCM is more than wrangling code and bug fix branching. SCM in the corporate environment has other requirements to fulfill that might be new to a developer first exposed to Git in an open source or school environment. Security, managing high contention environments, audit-worthiness, IP control, business processes, and large binary assets are some of these requirements. In this role, Git is not the right tool for the job.
So we are left with a problem- Git makes you a better developer through powerful tools for code manipulation, but wasn't created to fulfill the needs in corporate SCM environments.
Peanut butter cups
I teased at a resolution to this tension in my previous article "Perforce and DVCS: Two great tastes that taste great together". One solution is to follow my father's advice (rather than his example!) and use the right tool for the right job. For the Git power-user, Git excels at developer-scale code wrangling, and Perforce excels at everything else. Our "peanut butter cup" becomes a hybrid Git-Perforce environment, where Git is an application used by the developer locally, and Perforce commands the centralized environment. Sound familiar? Sure it does- that's using Git in the role of a Perforce client!
Git as a Perforce client
You might be thinking that is already happening through use of Git-Perforce gateway tools like git-p4 and you would be absolutely correct. That's why Perforce is working to improve the git-p4 open source project, and working to develop a strong relationship with open source communities where we share this common interest.
By the way, if you've gotten this far in the article and were really looking for a tutorial on using Git as a Perforce client today, here is our Knowledge Base article on using git-p4.
There's room to go further, and make it easier and more productive to use Git along with Perforce. One obvious opportunity is to allow Git-Perforce gateways to take advantage of new code line management in the 2011.1 release of Perforce Streams. Another is to provide a convenient and integrated way to version large binary assets not suitable for versioning directly in Git. We're experimenting with visual tools for managing and visualizing the workflow between many Git repos backed by a Perforce server. Perforce then forms the trunk of a tree at the base of all your Git repositories, a trunk that gives you all the versioning power, security, audit-worthiness and process control you need to safely run your business.
We've got more ideas, but more importantly we are reaching out to the community for your ideas. After all, you are going to be using and benefiting from these tools, and we want to do what we can to make that as productive an experience as we can.
There's more to DVCS than Git
No discussion of DVCS tools with Perforce would be complete without a mention of P4Sandbox, an all-Perforce product solution providing the most commonly used DVCS features enhanced with special Perforce-only features. Further down the road, there are plans to bring some key scaling capabilities revealed by DVCS architecture into the Perforce server itself.