Hi, IIRC it was you who started the c# port of git? What happened to it? On Sat, 26 Jan 2008, Govind Salinas wrote: > 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 > 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
