Friday, January 25, 2008

Introducing Pyrite!

Introducing Pyrite. Combining the best of git and Mercurial.

I have been following the Distributed Source Code Management for some time and I think it is a wonderful tool. I have looked extensively at both git and Mercurial and there are several things I like about both of them.

From Git I like.

  • Ability to re-write history
  • Speed
  • Lightweight versatile branches
  • Rebasing
  • Squashing

From Mercurial I like.
  • Easy as pie to set up an ad-hoc web server
  • Cross Platform (works well on Winders)
  • Extensibility, get full access to repository internals from your own python scripts
  • Python, chalk it up to personal taste, but I would rather work in python or another high-level language
I think it is possible to get the best of both worlds. So I am looking at writing something that will be a git repo at its core, but have Mercurial-like properties for ui and add-ons.

Rather than try and re-implement git internals, I think it is best to re-use them. So the project will take place in stages.

  1. Build a wrapper over git plumbing that allows me to have the user interfaces that I want.
  2. Help the libification effort in git so that I can use git code straight from python.
  3. Start stripping away non-performance-critical C code and convert it to python code to help interoperate with extensions and GUIs
There are 2 main benefits that I am looking for with git libification. One is, if we can reduce the amount of code that has to be compiled in C to a small enough subset, we should be able to build without the need of Cygwin or Msys. The other main benefit is that if everything lives in the same process, then we should be able to reduce the overhead for doing some operations that require forking and execing. As you chain operations you can reuse data in their native structures and not have to re-parse them as they are passed on stdin or the command line. Also, while fork/exec may be relatively cheap on Linux, it is very expensive on Windows. I am hoping that the result will be a net performance win, even when the overhead of python is taken into account.

Since it will be a git repository in fancy dress, the goal is to keep it fully compatible with git such that you can clone/pull/push to and from a git repository seamlessly. Or even use standard git in your pyrite repository and vice versa.

I have set up a repository on tuxfamily that should be in the links bar on this blog. I don't have an issue tracker or a Wiki yet, but hopefully there will be enough interest in this project that they will become necessary. I will be adding a mailing list too. In the meantime, if you are interested in helping with the project please email me. I also need a logo and I have no artistic talents.

About the name: Pyrite is "fool's gold." I chose the name for a few reasons. Because it's fool's gold, it has some connection to git (an idiot), Because it's a metal, it has some connection to mercurial. Also python projects like to be called pysomething. So the name worked out rather well.


Jakub Narebski said...

From the description here it looks like Pyrite is (will be) something
in between porcelain (SCM layer) like (now deprecated) Cogito, StGit,
Guilt, and plumbings / reimplementation of Git, like jGit/eGit in Java
and (planned?) Widgit in C#, rather than new SCM, isn't it?

Govind Salinas said...

Yes, I guess it's going a bit far to say that it's a new SCM since I
will be re-using the git internals. Mostly I said that because I hope
to re-implement large parts of it. It is more than a porcelain layer
though. I prefer to think of it as a system based on both tools.