GitSync allows you to use Plastic SCM as a GitHub (or Codeplex, or BitBucket... or your company's git server) client.
Is GitSync a new Git client?
Technically not. You would be using Plastic SCM on the client side but being able to push/pull to Git servers (using https or git protocols, no ssh yet).
So... you just created a bunch of scripts on top, right?
Not really. Indeed... not at all.
We started supporting the fast-export/import format long ago since it greatly simplifies the migration to Plastic SCM (considering almost everything is able to get moved to Git). But then we decided that while it was able to do a good job getting Plastic in sync with Git it was not smooth enough.
The first idea was to have some sort of local Git repo then use something like GitSharp to import/export... but it wasn't good enough because it forced you to have an intermediate git repo.
Then we decided to teach Plastic the git network protocol... Fortunately libgit2 exists and we took advantage from it.
So, no, GitSync is not a ton of scripts doing fast-import/export, it is actually a layer able to do push and pull directly to a remote git server over the network. It implements the smart-protocol and:
- it can negotiate with a remote git receive-pack to upload data (negotiating which changesets/commits are needed and generating the correct pack file from Plastic repository data to be sent to git)
- it can also negotiate with a remote upload-pack to decide which commits need to be packaged, download the pack and import it into Plastic
Definitely, we made Plastic speak the git protocol.
What about concurrent changes done in Plastic and Git?
The point is: since Plastic SCM handles the same concepts as git (DAG, commits, merge links, and so on) it is rather easy to share even the merge tracking. You do a merge in git, fine, you can get it back to Plastic. You do a merge in Plastic, fine, you can push even the merge link back to Git.
The most difficult point for us to handle is related to the "precise item tracking" we do (and git doesn't since Mr. Torvalds doesn't believe in that). Plastic has an internal id associated to each file and directory. It means we can easily handle tons of merge conflicts that are hard to track for git (like a divergent move, where you move the same file to two different destinations in two branches, then modify both files, then you merge... it is trivial for Plastic). The downside when importing from Git is that we need to actually "track" precisely what happened to our items... But it seems we made our way around it.
Find more info about how the conflicts are managed here.
At the end of the day... what's the point of GitSync?
Well, being able to talk to the most widely adopted DVCS seems to be a good idea since we have users who need to contribute to git projects.
Also, being able to use Plastic, especially if you're a Windows user, and still contribute to GitHub or any other Git repo... looks like a good idea too. We think it can ease the adoption of Plastic in certain environments, which is always a good thing.
Finally, we walked half of the path towards full interop: we already have the "client side", and we're working on Plastic as an optional Git server: you'll be able to push/pull from git to Plastic... but that's a different story :-)
We need testers
We need brave volunteers to adopt GitSync and give us feedback. In order to motivate you guys to join the program we will be selecting 10 top contributors and giving them an iPhone... :-)
You can find all the details here.