Git Fusion enables Git and Perforce users to share file versions using the tool and workflow they each prefer. While Perforce users check out and submit their files, Git users can clone repos and push their changes on the same files using Perforce as a remote. Perforce functions as the repository of record by keeping a copy of each file version and all relevant metadata.
Git Fusion employs user created views into Perforce to create Git repos by mapping parts of the Perforce depot. There are two “methods” to complete this mapping. The first is to create a configuration file for each repo. The second is to setup a client workspace. The syntax for both is the similar and is referred to as a repo view. The difference between each is the repo config file enables the creation of branch definitions upon initial setup.
Git Fusion uses two “types” of repo configuration files which reside in the .git-fusion depot on the Perforce server. The first is the global configuration file and it is created automatically at install. From here, you would setup default global parameters such as character set preferences, branch enablement, and author permission requirements.
Next is setup of “repo specific” config files. These are typically created from template files distributed with Git Fusion. They enable you to define an unlimited number of branches and Unicode character sets. Once configured, they are stored in the relevant repo directories of the //.git-fusion depot in Perforce.
Alternatively, you can use a Perforce client workspace to map a single fully-populated Perforce branch to a Git Fusion repo. Git Fusion generates the repo configuration file for you and then copies the relevant files from Perforce to create a repo in Git Fusion. This approach does not allow you to define branches when the configuration file is first created, but you can edit the file later to add branch definitions, as long as the additional branch definitions don’t affect Git history.
The administrator can initialize repos at the time of configuration or if they want to prepopulate large projects. Repos can also be initialized after configuration by the Git users simply by cloning the repo. Administrators can also import, modify and delete repos. More details on the steps for each these processes can be found in the Git Fusion Guide.
Let’s take a closer look at the mechanics of two people working on the same file at the same time. We have the Talkhouse project mapped between Perforce and Git Fusion in the p4gf_config file. //depot/talkhouse has two branches, main and dev. //depot/talkhouse/main has been mapped to git branch 'master', and //depot/talkhouse/dev to git branch 'dev'.
Liz is using Git. She clones the Talkhouse repo and performs her edits on eWidget. Once completed, she pushes the file to the repo’s master branch on Git Fusion. Sam is using a P4 client with a workspace mapping to both branches on the Perforce server. He performs a sync on the eWidget file in the main branch, makes his edits and then performs a submit.
Meanwhile, Liz was continuing work on the same file as Sam. Before she can push her changes back to the remote, she has to pull Sam’s changes and merge the files. Once the merge is completed, she pushes the updated file back to the repo.
With the file securely stored in the Perforce server, other Git users can pull changes to get the latest version, and P4 users can sync files to their workspace.
This concludes the intro to Git Fusion repos. For more detailed information on setting up repos, please review the Git Fusion User guide on perforce.com.
Thanks for watching.