Hi folks,
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.
Currently the project is in its infancy. All that exists is a help
system, but the help is sort of a roadmap for what I want to bring to
users.
Please give me any feedback that you think may help the project or
make it more desirable for people to use. You can respond to this
email or leave comments on the above post.
Thank You,
Govind.
"Govind Salinas" [off-list ref] writes:
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.
From the description there 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?
--
Jakub Narebski
Poland
ShadeHawk on #git
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
On 1/26/08, Jakub Narebski [off-list ref] wrote:
"Govind Salinas" [off-list ref] writes:
quoted
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.
From the description there 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?
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.
-Govind