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.

Direct push/pull from Plastic SCM to Git

Thursday, October 18, 2012 Pablo Santos 14 Comments

Plastic SCM is now able to speak git protocol language! What does it mean? Basically, Plastic now can push and pull directly to remote git servers using both native git and https protocols, which includes well-known sites such as github, BitKeeper, codeplex and many others!

The problem

When we started developing the git-bidirectional synchronization with Plastic SCM we had the following scenarios in mind:

  • Developers already using Plastic SCM who want to contribute to projects in sites like github, codeplex, BitKeeper and others.
  • Developers working on teams using Git as primary server who prefer to use Plastic SCM but need to contribute changes back to the main server.
  • Teams gradually adopting Plastic SCM who need to contribute to other teams on Git.

The solution

We went the hard way: we didn’t come up with some sort of intermediate script to convert changes from one system to the other, imposing a ton of limitations (you might have read of solutions like this during the last weeks, from other vendors :P), but we actually implemented the git network protocols in Plastic, so it can directly pull and push to git.

Plastic will start a negotiation phase with the remote git server, as a git command would do, speaking the same protocol described here. It is a core feature, not an add-on script.

Pulling changes from git

And it is really simple to use, all you need to “pull” changes from a remote git server is the following:

cm sync textmate git https://github.com/textmate/textmate.git

Assuming the local “textmate” repo is empty, it will calculate the changesets and branches it needs to pull from the remote github repo, and will pull them.

In order to pull new changes done at the github side, you’ll simply re-run the same command:

cm sync textmate git https://github.com/textmate/textmate.git

And it will now calculate and pull only the new changes made at the git side, if any.

Pushing changes to git

The same command is capable of calculating what’s new at the Plastic SCM side, negotiate with the remote server and push the changes.

The unique value

There are actually two things to consider:

  • For Windows developers contributing to projects on GitHub, BitBucket, CodePlex and so on: we give you a fully featured DVCS, designed for Windows users, with all the GUI features you can imagine, and ready to push your changes back to Git.
  • For current Plastic SCM developers: a way to interoperate with external Git repos, if that’s a concern for you.

Feature list

The capabilities of the current beta that we will be announcing on the coming days are:

  • Full push/pull to remote git servers, including all commits, comments, branches, merge tracking and tags.
  • Conflict management: it is possible to make changes on the same branch on the git and Plastic sides concurrently and Plastic will be able to handle the situation, pull the changes, request the user to run a merge, then push the solved conflict (as you’d do if you just were using a full git setup).
  • No limits on adding/deleting or moving files at any of the two sides.
  • Full merge tracking: you can merge at git side and Plastic will recognize the merge tracking, and the same is true in the Plastic to git direction. That’s the benefit of Plastic SCM and git being full DVCS! :)

How it works

Since an image is worth a thousand words, let’s go, step by step, through an entire push and pull process:

The image above shows the initial scenario: you’ve a git repo and then you pull it on Plastic. As a result you get an exact clone with the branches and commits you had in Git now converted to Plastic, and what’s best, able to be rendered in the branch explorer!

The next image shows what happens when a new commit is created on the Git side, and how the “pull” from Plastic SCM will retrieve it. Instead of just performing a simple change, the figure shows a merge from “big_feature” branch into “master”. The result in Plastic SCM mimics what happened at the Git side, adding the merge link (which is rendered as a “green line”) on the Plastic branch explorer.

The next step is performing a change in Plastic SCM and pushing the change to Git. In order to create a more complete example, instead of just creating a new changeset, we will also perform a merge.

The changesets “6” and “7” are created on the Plastic side then they’re pushed to Git. As you can see on the figure below, the merge information (multiple parents on the git repo) is also sent from Plastic to Git.

So far the changes were done at one side or the other, but not at the two sides concurrently. The following picture shows what happens when developers work on the same branch at the same time.

One new commit is created in git (on green) and a new one in Plastic (orange).

If now the Plastic developer tries to “push” to Git, an error will show up since there are conflicting changes (same that would happen on a similar scenario on a pure Plastic or pure Git setup). The steps to follow are:

  • First push the changes from Git
  • A new “subbranch” will be created placing the “88ffa” changeset correctly.

Everything will be handled by the “cm sync” command, no need to run an explicit pull first.

Now the next steps will be resolving the merge conflict at the Plastic SCM side, and then completing the push:

At the end of the day, both repositories will look the same, and will let developers work together at both sides.

Next steps

We’re about to release a “beta program” so we’re looking for enthusiastic developers who would use Plastic SCM to contribute to GitHub projects (or CodePlex projects, or Git projects on BitBucket) and will send us valuable feedback. Of course we’re also open to any other scenario, like enterprise teams using Git as a central repo with members who would prefer to use Plastic.

As you can see, now Plastic SCM can act as a full GitHub client… probably the most powerful one so far for Windows.

The “sync process”, as of today, is just available from the command line (cm sync command) but the rest of the GUI will be fully functional and is what you’d be using on a daily basis prior pushing to Git.

We’ll be launching a registration site soon, but if anyone is willing to try the beta already, please send comments to the post and we’ll get back in touch with you!

Watch the preview 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. This is incredible news. Well done guys. GitHub for Windows my arse! :-)

  2. :) Thanks stimul8d! Would you like to join the alpha-testing program?

  3. Oh, that is something I'm looking forward to. Though, a set of questions:

    1. Will it handle file:// paths? Or does it need to be via HTTPS?

    2. How about http:// (no HTTPS)

    3. ssh://?

    4. How does it handle the evil twin (since git doesn't really track file id's that much from my impression)?

    5. Plastic handles folder tracking but git doesn't. Is there any gotchas when that?

  4. @D. Moonfire

    1. We're handling direct connection to the server, no direct connection to file://. The goal is to use plastic as "github client", not to clone another git local repo... In fact, locally accessing the git repo would have been much easier to do :)

    2. Sure, we do support http too.

    3. No ssh support yet I'm afraid

    4. and 5. Yes, of course, if there are features that one of the two don't handle, then it could be a potential problem. In the case of the evil twins: git doesn't really mind, we do, so it will depend whether you run the merge on git or plastic side.

    Would you like to give a try to the alpha??

  5. Well, I've mentioned my dislike Plastic's handling of identical evil twins in general (seems to happen in our environment fairly frequently, but I also blame VSS for that).

    I wouldn't mind trying the alpha, but it will be 2-3 weeks before I can really get down into it (we have a December release). I also want to give feedback on the command-line side of things since that is how I usually work.

    Oh, another question. We are having trouble importing VSS into Plastic, so we tried doing a VSS to Git to Plastic conversion but that also choked. With this, could we do a VSS to Git conversion, and then sync a (very) large Git tree into Plastic?

  6. Hey! For the VSS import thing... I recommend you contacting our support team or the forum... better than in this thread :)

  7. This is awesome and potentially game changing for Plastic and Codice!

    - Greg

  8. Great news Pablo!!!

    I'm very impressed by this feature! Maybe I can bring some friends of mine to the "non-shell side of the force"!
    Some friends are using git in their work and they were kind of reluctant doing using the old sync ways! :)

    Just keeping the old doubt of D. Moonfire about evil twins, if all the merges and folder tracking were done in Plastic, it will not have any problem pushing the changes back to git, right? :)

    Can I join the beta program? :))))

  9. Hi again, another question:

    How is licensing doing if I pull a project with more than 15 different users/commiters?

    I'm using the Community Edition, so, I can't get more than 15 users...

  10. Hi Cidico!

    > I'm very impressed by
    > this feature!
    > Maybe I can bring some
    > friends of mine to the
    > "non-shell side of the
    > force"!
    > Some friends are using
    > git in their work and
    > they were kind of
    > reluctant doing using
    > the old sync ways! :)

    It would be great if you can ask your folks to give it a try! :)

    > Just keeping the old doubt
    > of D. Moonfire about evil
    > twins, if all the merges and
    > folder tracking were done in
    > Plastic, it will not have any
    > problem pushing the changes
    > back to git, right? :)

    Well, once the conflict is solved, you just have to push to git, so whatever you solve in plastic will be marked there

    > Can I join the beta program? :))))

    Sure!!! :)

  11. @Cidico: regarding the CE: sure, we've to check this. It is a good point to add the alpha program :)

  12. Just can say WOW!!

    And also VIVA PUCELA!!

  13. I'd like to participate in the Beta program - I have a couple of repositories on GitHub. What do I need to do next?

  14. Send me an email and I'll send you all the info, ok?

    We're announcing a new release with even more stuff, so it is a great moment.

    Reach me at pablo at codice.es