Git Fusion with Perforce

Git is a phenomenon. Distributed software configuration management (SCM) for Linus Torvalds – and for everyone else who thinks that managing Linux is a big project. Git is sexy; distributed SCM, with everyone having their own repository, is Agile; and Git has some nice features for controlling what people are allowed to add to the definitive repository for, say, Linux. Which means that Git workflow is a bit different to, say, Subversion workflow.

On the other hand, Git doesn’t seem to meet the needs of organisations – such as Google – that see the Linux project as rather a small-scale thing. Anecdotally, too, the ease with which new repositories can be created can result in chaos, with different flavours of a product appearing for different groups of users (although good Agile developers will have the discipline to cope with this, as Agile becomes fashionable, not everyone talking Agile has the discipline needed to make it work). A friend of mine has found difficulty finding large commercial organisations using Git or, at least, prepared to talk about it.

Now Perforce, which Google uses for its SCM, tells me it has come up with a novel approach to the Git issue – Git Fusion. In its essentials, this seems to be the use of Perforce to manage Git repositories – Git users can carry on without changing what they do; but a central Perforce repository (with replication for distributed support etc.) makes sure that the Git repositories are managed in sync. The best of both worlds for Git users hitting Git’s issues and for organisations using Perforce that have pockets of Git usage. And, an unexpected bonus for Perforce: developers using Apple’s Xcode development environment can now use its built-in Git integration with Git Fusion – without making any changes to their environment. Since Git Fusion is all on the server and no changes are required on the client-side, any Git-enabled client tool (such as Xcode or SourceTree) could be used; and developers using Git Fusion need not even know that their remote repository is actually Perforce.

Seems interesting to me, although I anticipate some cultural issues – as the sort of people who choose Git (possibly, in part, to cock a snook at a management which imposes “enterprise tools” on them) may not be the sort of people happy with a commercial product like Perforce (although it is free for educational establishments and open source projects). The transparency of Git Fusion will help here – users don’t have to change any of their workflows, they simply clone repositories to their local system, and the use of Perforce tools such as Time Lapse View and P4Merge, which aren’t available with Git, isn’t required (although it might be useful). There’s a webinar on “Improving the Git Experience for Everyone (without compromise)” here. My view is that SCM is a Good Thing and anything that reduces siloisation around particular vendors/products is welcome.