Re: Dropping Git.pm (at least Git.xs)?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dear diary, on Sun, Sep 10, 2006 at 07:59:54PM CEST, I got a letter
where Sam Vilain <sam@xxxxxxxxxx> said that...
> Dennis Stosberg wrote:
> > Having perl bindings to git internals and sometime in the future to a
> > libified git is a great thing.  It will allow people to do interesting
> > things, quickly trying concepts without having to write any C code.
> > And I expect that gitweb can be sped up remarkably by using Git.pm (no
> > forking, parsing of command output often not necessary, easy caching of
> > frequently cached data across calls, etc)
> 
> FWIW, I have been starting on a perl implementation.  It uses the
> Git.pm, but not for anything *that* important.  It's still very young,
> but once I have reading and writing files basically working, I'll
> release it to CPAN separately - no reason it needs to be distributed
> with Git itself.
> 
> See http://utsl.gen.nz/gitweb/?p=VCS-Git

I think those two can coexist quite well. Yours aims for a nice and
slick object interface, while mine is just about wrapping Git interface
in Perl, without building any elaborate object model (it would provide
any only if underlying libgit would in the future, I guess).

Now, I'm not actually opposed to making Git.pm provide more
object-oriented interface, and it is thus obvious that it might be due
to consider a merge of the two modules, but

  (i) Git.pm ought to stay bundled with Git, simply to be useful for Git
itself and the perl scripts it carries. Without Git.xs and associated
portability concerns, Git.pm might finally actually help things. :-)

  (ii) People would thus go mad about external dependencies like Moose
or even Class::Autouse, so Git.pm can't rely on anything like that
(unless it bundles it, which is not quite practical in case of Moose).

  (iii) (Besides, Moose may be the next totally cool and all-popular
thing in the world of Perl soon, but so far, I'd be personally careful
about using it for the "official" interface, since Git Perl developers
would apparently have to learn another way to do objects in Perl before
able to use Git, and other Perl developers going by couldn't read (and
fix/enhance) the code without doing the same.)


Dear diary, on Mon, Sep 11, 2006 at 12:13:01AM CEST, I got a letter
where Jakub Narebski <jnareb@xxxxxxxxx> said that...
> Could you please put appropriate information on GitWiki
>   http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
> Perhaps it would be good time to start new section, Git Implementations,
> and put egit (Java GIT library and Eclipse plugin) there too.

This really isn't a Git reimplementation (thankfully).

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]