Who we are

We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

If you want to give it a try, download it from here.

We also code SemanticMerge, and the gmaster Git client.

GitSync is out - a native Windows DVCS connected to GitHub

Wednesday, March 13, 2013 Pablo Santos , 6 Comments

Hello world, we just launched GitSync, virtually turning Plastic SCM into a full-fledged Windows client for Git.

GitSync allows you to use Plastic SCM as a GitHub (or Codeplex, or BitBucket... or your company's git server) client.

You can use the Plastic SCM tools including the Branch Explorer (see below) and still contribute to Git.

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?

Well, we handle that. In fact I wrote a post about the details months ago and later when we added GUI support to the push and pull process.

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.


Pablo Santos
I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code. You can reach me at @psluaces.


  1. 1. I didn't really get this: Can this be used to keep git and plastic in sync constantly all the time?

    2. Can we use this to sync a local git repo? I'm struggling with it for about an hour and couldn't figure out how.

    If all we have is that "cm sync" command line, I'd guess (1) is "no" and (2) is "as long as you have a web server".

  2. Hi,

    Check this post for more details

    1) It can be used to push and pull from plastic to git. So yes, they can be in sync. They'll sync each time you run a synchronization.

    2) No, you need a git server because we do use the network protocol. We thought using a local one wouldn't be helpful since what most people will do is to use plastic as a git client. Makes sense?

  3. Wow, blazing fast answer there, pablo! I had found many links out there about the gitsync, but not that one, thanks!

    You mean if you did allow using a local git repo people would use plastic as a git client?

    Yeah, ok, I guess it all makes sense now. Sounds good. :)

  4. Wow, blazing fast answer there, pablo! I had found many links out there about the gitsync, but not that one, thanks!

    You mean if you did allow using a local git repo people would use plastic as a git client?

    Yeah, ok, I guess it all makes sense now. Sounds good. :)

  5. Hi again,

    No, I mean we discarded using the local git repo because we thought it would be more useful to provide access to remote repositories only.

    Since you are going to be using Plastic, having an extra repo local copy in git probably doesn't make sense.

    I guess you can access your git repo by git:// or http protocol

  6. Right click on a branch, "replication menu" (this *MUST* exist) then an action called "sync with git" :-)