Announce 0.01prealpha

Hey Everyone,

I am proud to announce the first pre-release of Pyrite 0.01prealpha. You can pull from git://gitorious.org/pyrite/mainline.git or http://git.gitorious.org/pyrite/mainline.git ( I think I will use gitorious for hosting since tuxfamily doesn't have an http clones, although I will sort-of miss the RSS feed).

Why such a timid name? This is because it has taken me longer than I wanted to reach a point where I felt others could reasonably use and contribute to the project. There is still much work to be done before it is ready for a general purpose release. However, I need to see if people are really interested in both helping develop and, more importantly, using Pyrite and I feel that getting a release out there will help me gauge that.

When I started this project, I had a good idea of what I wanted to accomplish but I wasn't entirely sure how I would do it. At this point I have an idea of how the interface should be presented and I will work to get it right. I hope people will have input on what improvements they would like to see to the UI.

Other things that I want to do before making a general purpose release is to tie up some loose ends like proper rebasing and a graphical merge tool (at least support for external merge tools). That's just the tip of the iceberg though since I have plans to also do a gui and a web interface.

Feel free to contact me about this if you are interested in using, testing or developing.

Thanks,
Govind.

Update:

I got several responses about how the announcement was short on
details. You guys are absolutely right, I blame the benedryl and the late
hour. Anyways...

Pyrite, in its current form, is a git porcelain. Its focus is to reduce the
learning curve, increase portability and, basically, make it as easy to
use as possible. I say "in its current form" because this is simply the
first stage of Pyrite's development. When Pyrite is complete I expect
that it will a cross between a porcelain and a python re-implementation
(similar to what the egit/jgit folks are doing).

I think Pyrite is a good idea for several reasons. First and formost,
there are several SCMs out there that are considered more usable
than git. Hg, bzr and darcs all have a more user friendly reputation
than git. There are even things to be learned (UI wise) from non
distributed systems. However, git would have a very difficult time
making the sort of changes that would be required because they have
an established user base and many people have gotten used to the way
it works currently. Such changes would also break a lot of automation.
Also, git is both plumbing and porcelain and a lot of that shows in the
interfaces. It provides many commands and options that a user would
very likely never use. A project like Pyrite offers a break from the
interface that people can choose to take, leaving those that are used to
git or like the current way of doing things alone.

I think it also offers advantages in terms of portability and ease of
development.

The foreseeable future of Pyrite is this...

0.01) Add a couple of bits of functionality that are think are missing for
general use and make some internal changes to facilitate
development. Also, as I stated above, I now have a better picture
of how I want the command line UI to behave, so I will be changing
options and other things.

0.02) Add the GUI. I have already started work on it, but it is only
about 1/3 done.

0.03) Built in webserver. This is similar to the "hg serve" command. I
think this is a good idea because there are times where it just
isn't worth it to set up a webserver to share your changes.

0.04) Move to using libgit where possible.

0.05) See where it makes sense to the git commands I am using as
python. Things that are already scripts are obvious candidates,
but also things that are simple wrappers over other git
commands.

0.06-1.0) Get feedback from users, fix bugs, add features and repeat.

I hope I was better able to answer people's questions here than in my
previous mail.

Thanks for the feedback,
Govind.

Pyrite Graph Preview

Quick preview of the Pyrite history graph. Still a work in progress...

Pyrite GUI

It has been a while since I have posted anything on here. Here is something to make sure people know about the current status of pyrite. I have been working toward getting pyrite able to handle the day to day activities of being a git wrapper. That is, it is a pass-through porcelain on top of git. The current TODO list looks something like this.

• Get basic commands to run on the command line. (this one is mostly done, I just have to do some of the more interesting things like rebase, cherry-pick etc)
• Add support for styles and templates. Think pretty-print or styles/templates under Hg. ( I can probably tag v0.1 at this point)
  
• GUI (see below, should be v0.2)
  
• Built-in HTTP server. This will be similar to hg serve and use a similar framework. The hg serve is very nice and one of the things that prompted me to start this. (v0.3)
• Convert direct shell commands to c extensions that do the shell commands. This doesn't make much sense by itself, but is very nice for the next step...(v0.5)
• Convert to libgit where libgit is currently implemented. Only part of git functions as a c library, so much will still have to be done in sub-processes. This will probably take a while (v0.9)
• Squeeze out bugs and I can call it v1.0.

After that we will see where things go. I expect that much of my work will go into converting the places where I am forced to run sub-processes to library functions in git.

Now on to the fun part, the GUI.

Long ago, I was temted to create a GUI for git that ran on Windows and was written in C#. This was called Widgit. I did some work on it, but I could not convince my co-workers to be interested in git, and without someone to use what I was writting, it seemed kind of pointless. Fast forward a few months and I started working on Pyrite. Since this was more geared to the Linux crowd, I felt I could use python and GTK+ to make the GUI, but I liked several of the Ideas that I had for Widgit and I thought I could reuse them. Here is what the basic view looked like...

There was a status pane also...

I was also fairly proud of the commit view filter, which I thought was handy...

And I plan to have all of these elements in Pyrite. Also, I really like some of the things I have seen in other GUIs that I want to borrow. For instance the graphical tree structure of Giggle is very nice and done using Cairo. Also, it shows the diffs a la gitk.

So all these things are nice. I have done a little bit of work on the GUI, but its just getting started. Here you can see what the current status of it is...


If anyone has any suggestions, I will be glad to hear them.

-Govind

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.