Re: [ANNOUNCE] Pyrite project.
Hi,
IIRC it was you who started the c# port of git? What happened to it?
On Sat, 26 Jan 2008, Govind Salinas wrote:
Show 7 quoted lines
> I am starting a project that I hope some of you will be interested in.
> I have been looking at DSCM tools for a few months now and I have
> come away liking different aspects of different systems. The project,
> called Pyrite, aims to combine the best features of git and Mercurial.
>
> Please stop by http://pyrite.sophiasuchtig.com/ to see the
> announcement. Links to the public repo in there.
I do not like this type of announcement. A link is good on IRC, but on the mailing list you can include a (possibly abbreviated) version of it so that people are not inconvenienced.
So I will quote your linked page, and insert my comments
Show 36 quoted lines
> 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.
That should be easy enough.
> 2. Help the libification effort in git so that I can use git code straight
> from python.
That should also be easy enough; there was a GSoC program, and you could just go there and help that effort, instead of reinventing the wheel.
For your convenience:
http://repo.or.cz/w/git/libgit-gsoc.git
> 3. Start stripping away non-performance-critical C code and convert it to
> python code to help interoperate with extensions and GUIs
I am absolutely no fan of "extensions". You keep breaking other people's code if your core introduces changes; see for example the libgit.a issue with cgit.
> 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.
This effort would be better helped by converting more scripts to builtins, _not_ by reintroducing the dependency on python.
> 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.
We have relatively few fork()s and exec()s by now. Eliminating them would mean that you have to put in a huge effort to undo the one-shot paradigm in a lot of operations.
> 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.
You might want to look at Han-Wen's git-dump tool (although I think that it is misnamed; something like git-query would be better IMHO).
> 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 expect that Mercurial people will not be happy...
Ciao, Dscho
