develooper Front page | perl.perl5.porters | Postings from January 2009

Re: Git.pm

Thread Previous | Thread Next
From:
philippe.bruhat
Date:
January 5, 2009 06:51
Subject:
Re: Git.pm
Message ID:
20090105145113.GD8962@plop
On Mon, Jan 05, 2009 at 03:09:39PM +0100, demerphq wrote:
> 
> Whats not so clear to me is whether a new git framework should be
> staged out of git.git.
> 
> And I personally feel there is a good case for writing a complete new
> framework, especially if the new framework can be a) git version
> independent (a good reason not to put in git.git), and b) capable of
> being used to reimplement Git.pm as a wrapper.
> 
> Git.pm as it lives in git.git has the problem as far as i can tell of
> being bound to the installed version of git, which means that you
> can't use it to implement a workaround layer to make tools version
> independent. You essentially have to mandate a dependency on a version
> of git that you may not be able to change, where you would be able to
> upgrade the perl framework.

Also, the current Git.pm make it very difficult to work with git commands
that use both STDIN and STDOUT, since the bidi_* commands are incompatible
with the rest of the commands (specifically, they expect your program
to have it cwd under the git repo).

http://marc.info/?l=git&m=122480934131798

> Perhaps this is really a case for two layers, that abstract things
> from either end. On one end you have the git.git controlled stuff,
> which allows them to do what they want, and on the other you have a
> CPAN based abstraction layer that makes it possible to work with any
> (reasonable) version of git.

This sounds like a very good idea.

-- 
 Philippe Bruhat (BooK)

 We laugh at stupidity because the alternative is to cry over it.
                                    (Moral from Groo The Wanderer #71 (Epic))

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About