Posted 29 November 2019 - 08:27 AM
It's kind of all of those things!
In my mind there are two components to it.
The first is a new kind of depot called 'graph' that stores git objects natively. Though you can't access them with a git client directly pointed to the Helix Core server, which brings us to the other part.
The git connector. It is similar to a p4 proxy but stores git repos that it transfers from the graph depot(s) on a helix core server.
Git client users then connect to the git connector in their office/region. Much like p4 proxies, you can have as many of these things as you want pointing to your main server. Or if you really want to go nuts and leverage Perforce's commit/edge architecture, you can point a git connector at an edge server. You can have the git connector populate itself on-demand or on a schedule, or both. If you set the entire server to pre-cache the git objects, then local users are cloning their git repos at local speed instead of (potentially) waiting for the initial transfer (if they're the first to request something, much like a p4proxy.)
The normal p4 command line clients can also connect directly to a graph depot in a Helix Core server, so you can theoretically use them in your normal build processes without much change. The increase in speed Perforce touts comes largely from the fact that in that case, you're syncing, etc. at p4 speeds, not 'git clone' speeds.
You can also submit with a p4 command line client, so you can have git and p4 client users working on the same code. The caveat there (in my mind) is that the graph depot is storing git objects natively, so no changelists (SHA's instead), to labels (tags instead), etc. It's git nomenclature with a p4 client, so p4 users in that case would need some git knowledge to know what's going on.
We haven't yet rolled it out to production, not sure when we will, but in my opinion it's pretty slick if you're growing into a shop that's been pure p4 but now has git demands. In our case the main problem/pain point is that we've been with GitFusion for a long time and converting is going to be a political and technical nightmare, if we want to convert long-running Gitfusion projects.
Currently unemployed, looking for work in Boise, ID!