[ANNOUNCE] Pyrite project.

[ANNOUNCE] Pyrite project.

[Govind Salinas]

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.

Re: [ANNOUNCE] Pyrite project.

[Jakub Narebski]

"Govind Salinas" <blix@sophiasuchtig.com> 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

Re: [ANNOUNCE] Pyrite project.

[Govind Salinas]

On 1/26/08, Jakub Narebski <jnareb@gmail.com> wrote:
> "Govind Salinas" <blix@sophiasuchtig.com> 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?
>
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

Re: [ANNOUNCE] Pyrite project.

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3989 bytes --]

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

Re: [ANNOUNCE] Pyrite project.

[Govind Salinas]

On 1/26/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> any particular reason you took this discussion off-list?
>
No, I am just an idiot.  GMail's defualt reply instead of reply-all
bites me every
friggin time.

re-adding the list.

> On Sat, 26 Jan 2008, Govind Salinas wrote:
>
> > On 1/26/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > > IIRC it was you who started the c# port of git?  What happened to it?
> >
> > Well, that was mostly so I could convince my co-workers to use git (and
> > to teach myself C#), but the idea was a non-starter at my company so I
> > abandoned it.
>
> I thought it was a GSoC project?
>
No, it was my own thing.

> > > >  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
> > >
> >
> > Yeah, I was looking at that when I was doing Widgit.  But last I checked
> > there had not been an update in several months, I figured the project
> > was dead.
>
> I should hope that it would make more sense to pick it up than to start a
> new project.
>
Totally agree.
> > > >  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.
> >
> > The nice thing about extensions is that you don't have to use them if
> > you don't want to.
>
> I know what the nice thing about extensions is.  My point was that there
> is also a pretty nasty side.  One that I am not prepared to accept easily.
>
There is another benefit too.  Have a bit of code that might be dangerous?
Put it in an extension and it can be tested in isolation, without the need to
rebuild the project (for people that offer to test for you).  Once it is ready
and tested for general use, it can beincorporated into the standard.

> > > > 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.
> >
> > So a couple of different things here.  Firstly, you should not see this
> > as introducing a python dependency to git.
>
> Well, I should hope so.
>
> > A libified, unified version of git all in C would almost certainly be
> > faster than anything done in python, even with the good stuff done in C.
> > However, and I know it's a notion that some people don't agree with, I
> > believe a small amount of performance (such as overhead from using a
> > JITed language) can be sacrificed for ease of development and maintain-
> > ability.
>
> I have no problem with rapid prototyping in shell or perl.  But the final
> goal has to be C.
>
> Ciao,
> Dscho
>
>

Thanks for the feedback.
-Govind

Re: [ANNOUNCE] Pyrite project.

[Johannes Schindelin]

Hi,

On Sat, 26 Jan 2008, Govind Salinas wrote:

> On 1/26/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > On Sat, 26 Jan 2008, Govind Salinas wrote:
> >
> > > On 1/26/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > >
> > > > Govind wrote:
> > > >
> > > > >  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.
> > >
> > > The nice thing about extensions is that you don't have to use them 
> > > if you don't want to.
> >
> > I know what the nice thing about extensions is.  My point was that 
> > there is also a pretty nasty side.  One that I am not prepared to 
> > accept easily.
>
> There is another benefit too.  Have a bit of code that might be 
> dangerous? Put it in an extension and it can be tested in isolation, 
> without the need to rebuild the project (for people that offer to test 
> for you).  Once it is ready and tested for general use, it can 
> beincorporated into the standard.

We have branches for that.  We don't even need an extension mechanism.

Ciao,
Dscho

Re: [ANNOUNCE] Pyrite project.

[Govind Salinas]

 Apologies, sending to the list.


 ---------- Forwarded message ----------
 From: Govind Salinas <blix@sophiasuchtig.com>
  Date: Jan 26, 2008 4:53 PM
 Subject: Re: [ANNOUNCE] Pyrite project.
 To: Johannes Schindelin <Johannes.Schindelin@gmx.de>





 On 1/26/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
 >   Hi,
 >
 > On Sat, 26 Jan 2008, Govind Salinas wrote:
 >
 > > On 1/26/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
 >  >
 > > > On Sat, 26 Jan 2008, Govind Salinas wrote:
 >  > >
 > > > > On 1/26/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
 >  > > >
 > > > > > Govind wrote:
 > > > > >
 >  > > > > >  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.
 >   > > >
 > > > > The nice thing about extensions is that you don't have to use them
 > > > > if you don't want to.
 > > >
 > > > I know what the nice thing about extensions is.  My point was that
 >   > > there is also a pretty nasty side.  One that I am not prepared to
 > > > accept easily.
 > >
 > > There is another benefit too.  Have a bit of code that might be
 > > dangerous? Put it in an extension and it can be tested in isolation,
 >   > without the need to rebuild the project (for people that offer to test
 > > for you).  Once it is ready and tested for general use, it can
 > > beincorporated into the standard.
 >
 > We have branches for that.  We don't even need an extension mechanism.


 If you have branches, you still need to pull the code and build it.  Extensions
 allow you to deliver functionality at will.  You can also deliver things with
 the standard distribution that not all users will want.  Imagine you had an
 extension to deal with cross platform issues like the case-sensitivity and
 unicode decomposing on OSX.  People who don't need this, don't ever
 incur the extra overhead.  People doing cross-platform can load them
 and people who aren't, don't have to.

 YMMV

 -Govind