There is no load on Perforce during normal Git activity.There is only communication with Perforce during clone/push/pull operations, as with any upstream repository.
What about performance? How many Git repositories can Git Fusion handle?
We have done performance testing and will continue to analyze the product as it evolves. Here are some notes and recommendations:
- The number of repositories is not as significant a factor as the size and use of the repositories. Use Perforce views to keep your Git repositories lean and mean.
- Pre-populate when possible.
- Avoid extensive use of 'git push -f'.
- Avoid extensive use of 'git rebase -i' to squash the last commit
- Limit the amount of merging between Git branches. Use rebase where possible.
Can Git Fusion connect through a proxy, broker, or replica?
Yes, connecting to a server through such peripheral components is supported.
Could I use Git Fusion to deploy data or feed a farm of build servers?
Yes, you could set up a view that captures the data in question, use it to populate a Git repository or set of repositories, and then feed the data into a build or deployment process. The only disadvantage compared to using a Perforce repository (or replica) directly is the loss of traceability: Perforce tracks what revisions are populated in a given workspace.
Are there any configuration tools for Git Fusion?
The virtual appliance includes a simple configuration tool for managing SSH keys. You can use P4V's graphical workspace editor to manage views, and you can use P4Admin's graphical protection editor to manage access control and groups.
Do I have to run p4gf_super_init.py on the OVA?
No, if you use the existing data in the OVA's p4d. That p4d has already had p4gf_super_init.py run on it to save you a step.
Yes, if you point the OVA's Git Fusion at a Perforce server other than the OVA's, or if you replace the OVA's p4d data with your own. Then p4gf_super_init.py will prepare your Perforce server for Git Fusion.
What happens if I obliterate Perforce data that is used through Git Fusion?
In order for this action to reflect properly in Git, you should also destroy and recreate the associated Git Fusion repository. All users should then clone a fresh copy of the repository.
The Git Fusion utility script p4gf_delete_repo.py can help with destroying a Git Fusion repository. Please contact Technical Support for assistance if you need to obliterate data that has already been exposed through Git Fusion.
Are there any limitations on using Git when I want to also use Git Fusion?
Git Tags are not translated into Perforce Labels and vice versa. Git Tags are however stored in Perforce, so when another Git User clones a repo containing the tags they will be visible.Does Git history get squashed when it goes into Perforce?
No. Each Git commit is recorded as a Perforce changelist.Does Gerrit work with Git Fusion?
Yes, at least in this scenario:
- You have some data that exists in Perforce.
- You export that data into a Git repository and use it to seed Gerrit.
- Future changes are submitted as reviews to Gerrit.
- Upon the approval of the review, Gerrit pushes the change to Perforce through Git Fusion.
This technique lets you use Gerrit as a workflow and code review system on top of Perforce. It leverages Gerrit's ability to mount another Git repository (in this case Git Fusion) as a mirror.
The major limitation is that changes made directly in Perforce (outside of Gerrit) would then need to be moved to Gerrit. It may be possible to do this with a Perforce trigger or Git hook.
Contact us for more information on this technique if you're interested.Does Git Fusion support Mercurial?
Not directly: we've built our solution specifically to be transparent to Git users. However, the open source Hg-Git extension provides some compatibility for Mercurial and Git Fusion. See this article:Git Fusion And Mercurial
.Can I use Git Fusion to work with XCode and Perforce?
Yes, XCode supports Git, so Git Fusion lets you effectively push from XCode to Perforce via your local Git repository.How are branches handled?
As of 2013.1, Git branching and merging are supported. Git branches can be mapped to Perforce depot paths. Git merges are reflected in the integration history between these branches in Perforce. Unmapped branches are referred to as "lightweight", as only the changes are tracked rather than the full branch, and are stored in Git Fusion's dedicated depot.
While Git Fusion supports sharing depot paths across repos, in Git, resources shared by different repos, are generally maintained in their own repository. The separate projects can then use the shared repo by including it as a submodule or other means.Can I use Git Fusion to import data from Git into Perforce?
Yes. Create a Perforce view that maps to an empty area in the Perforce repository. Use this view to push your existing Git data into Perforce through Git Fusion. (You'll need to mount Git Fusion as a new remote in your existing Git repository, then push upstream.)How are the change histories meshed chronologically when you import the Git repository?
Changelist numbers are always forwarding numbers. So when changes are pushed from Git to Perforce each change from Git will have a unique and forwarding changelist number. But the date/time of the change (when made in Git) is reflected in the Perforce submitted date. This means that it is possible, and even likely, that the sequence of dates do not match the sequence of changelist numbers. For example change#1 by userA might have a date of 2012/08/01, change#2 by userB have a date of 2012/07/31 because the date is actually when the change in Git was made and the changelist number is the sequence that it was committed to Perforce.Will P4Sandbox change with Git Fusion?
P4Sandbox is a Perforce end-to-end solution intended to provide popular DVCS features in a Perforce only environment. This new product is intended specifically for Git users or organizations using Git.How does this relate to git-p4?
git-p4 is an open source connector that is part of the Git distribution itself. git-p4 requires additional software and workflow steps for the end user, while Git Fusion provides a seamless Git experience.If I'm not using Git today, what's the benefit of incorporating it with our existing use of Perforce? What does Git add, that we can't already do with things like branches and shelving?
Some developers like Git's local branches and ability to work disconnected. However, if your existing workflow is working well, there is no need to change. You can also evaluate P4Sandbox for a 'pure Perforce' solution for offline work and local branching.Can I take advantage of all Perforce features in Git, and vice versa? How about job (bug tracking)?
Some Perforce features like labels are not visible in Git. Git tags, however, can be pushed to Perforce. If you are concerned about defect tracking integration, you can use Git hooks to enforce policy on the Git side, or Perforce triggers to enforce policy on push into Perforce.
As an example, assume you have triggers that demand that each changelist be linked to a valid Perforce job on submit. Git does not have the concept of jobs, but a Git user could reference a job number in the commit comments. Another Perforce trigger would then detect this information and take some action, like linking to a job.
Please let us know if you have specific use cases in this area.If you create a new view in Git Fusion, do you need to clone a new local Git repository? Do the SHA1s change?
Yes. SHA1s are maintained in Perforce at the repository level, and are only meaningful in the repository from which they came. If you have two Git repositories that have some overlap, then a change from the first repository that affects the overlapping files will be visible in the second repository but will have a different SHA1.
While Git Fusion supports sharing depot paths across repos, in Git, resources shared by different repos, are generally maintained in their own repository. The separate projects can then use the shared repo by including it as a submodule or other means.We have a Perforce branching structure that looks like this: //depot/MyProj/main, //depot/MyProj/dev, //depot/MyProj/rel. Can I include all of those branches in a single Git repository?
All three can map to Git's master branch. Or if you expect your Git users will need to merge between these branches, configure them as mapped branches in your Git Fusion repo configuration.How do you handle conflicts when pulling or pushing?
If you get a conflict when pulling from Perforce, resolve it normally using Git tools. If you get a conflict when trying to push to Perforce (i.e. your Git repository is behind Perforce), you should abort, pull and rebase, then push. It is similar to the merge down, copy up paradigm used in Perforce streams.Does Git Fusion help with managing large binary files in Git?
In the short term, you can use the Perforce views to only select the binary files that you need in a Git repository. That can help keep the repository size manageable. We are exploring a longer term solution that actually delegates the binary files to Perforce directly. If you have use cases or requirements in this area please contact us - we'd like to hear them!
Can I sync from and submit to Streams with Git Fusion?
As of release 2013.3 you can sync and submit to streams.
Pre release 2013.3 the workaround is to branch the files from the stream to a path in a non streams depot, then create a Git Fusion workspace that maps this non streams depot path.
As of release 2013.3 it is possible to work with Git Submodules.