Hi, I'm new on this mailing list and quite new to git too. I named on irc that
I develop mainly in Perl (http://search.cpan.org/~nkh/) when I do open
source. I heard that Git.pm needed some love and I can take over its
maintenance if there are things that need to be done.
I need to know:
- what needs to be done
- who was doing maintenanace before
- how do you want to release it (perl modules are best placed on CPAN
(too))
- what (and who) is depending on Git.pm
- what would be expected of me
As you may have seen in another mail, the Perl community is getting
interrested in git.
Cheers, Nadim.
From: Petr Baudis <hidden> Date: 2016-06-15 22:45:40
Hi,
On Wed, Nov 19, 2008 at 06:56:44PM +0100, nadim khemir wrote:
Hi, I'm new on this mailing list and quite new to git too. I named on irc that
I develop mainly in Perl (http://search.cpan.org/~nkh/) when I do open
source. I heard that Git.pm needed some love and I can take over its
maintenance if there are things that need to be done.
I need to know:
- what needs to be done
- who was doing maintenanace before
- how do you want to release it (perl modules are best placed on CPAN
(too))
- what (and who) is depending on Git.pm
- what would be expected of me
I know it's quite some time since you wrote this mail originally -
have you read the Lea's thread I have recommended? What is your current
plan?
I think the current rough consensus in the Git community is to go with
Lea's design and implementation after extending it with a nice way to
run arbitrary Git commands. This is also desirable since then we can use
her patches to make gitweb use Git.pm.
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
From: Jakub Narebski <hidden> Date: 2016-06-15 22:45:40
nadim khemir [off-list ref] writes:
(CC-ed Petr Baudis and Lea Wiemann).
Hi, I'm new on this mailing list and quite new to git too. I said
on IRC that I develop mainly in Perl (http://search.cpan.org/~nkh/)
when I do open source. I heard that Git.pm needed some love and I
can take over its maintenance if there are things that need to be
done.
I need to know:
- what needs to be done
- who was doing maintenanace before
- how do you want to release it
(perl modules are best placed on CPAN (too))
- what (and who) is depending on Git.pm
- what would be expected of me
As you may have seen in another mail, the Perl community is getting
interested in git.
Actually there are one and a half of Perl interfaces to Git: Git.pm
created by Pasky (who, as far as I understand is not a Perl hacker)
which is in git.git repository, and Git::Repo and friends created by
Lea Wiemann during her work on "gitweb caching" project at Google
Summer of Code 2008 (you can find her repository at git wiki page
http://git.or.cz/gitwiki/SoC2008Projects).
If I remember history of Git.pm correctly, it was first created as a
way to collect together and uniquify various versions of safe_pipe and
safe_qx which were used by various Perl scripts in git; something like
Perl version of git-sh-setup.sh for shell scripts... At first it even
used XS in parts, but the build system was deemed too unportable (it
depended on -fPIC). One of design decisions was to use Error.pm for
throwing errors; I'm not a Perl hacker, so I cannot say if this was a
good decision, and if implementation of this part is good.
Lea Wiemann work on Git::Repo and friends was created as object
oriented interface. It was build from ground up instead of reusing
Git.pm to be not encumbered by Git.pm cruft... unfortunately it means
also abandoning all the work that went in Git.pm to make it portable
(read: make it work with crippled ActiveState Perl). You can find
discussion on the design of Git::Repo and decision of it being clean
state implementation at link given by Pasky.
P.S. I have "[RFC] Git Perl bindings, and OO interface" half-written
(well, more like a third), a bit stalled. I'll try to find time to
finish it and send it to git mailing list.
P.P.S. "git grep 'use Git'" finds git-add--interactive.perl,
git-send-email and git-svn. Probably other Perl scripts (including
gitweb) could make use of it...
--
Jakub Narebski
Poland
ShadeHawk on #git
I know it's quite some time since you wrote this mail originally -
have you read the Lea's thread I have recommended? What is your current
plan?
I think the current rough consensus in the Git community is to go with
Lea's design and implementation after extending it with a nice way to
run arbitrary Git commands. This is also desirable since then we can use
her patches to make gitweb use Git.pm.
Hi,
Yes I read Lea's thread. My current plan is to:
- not rush
- analyse where the different modules are used and how (and document it)
- understand the process of working with the git team
- tell my fellow perl developers about this (done, so far very good response)
- confer with the people having git related modules (a few)
- gather ideas for what nededs to be changed (not much this far)
- put a development strategy in place
- understand the test mechanisms you've been using so far
- pray hard to any helping deity and get real
Cheers, Nadim.
On Friday 21 November 2008 03.56.51 Jakub Narebski wrote:
Actually there are one and a half of Perl interfaces to Git: Git.pm
created by Pasky (who, as far as I understand is not a Perl hacker)
which is in git.git repository, and Git::Repo and friends created by
Lea Wiemann during her work on "gitweb caching" project at Google
Summer of Code 2008 (you can find her repository at git wiki page
http://git.or.cz/gitwiki/SoC2008Projects).
If I remember history of Git.pm correctly, it was first created as a
way to collect together and uniquify various versions of safe_pipe and
safe_qx which were used by various Perl scripts in git; something like
Perl version of git-sh-setup.sh for shell scripts... At first it even
used XS in parts, but the build system was deemed too unportable (it
depended on -fPIC). One of design decisions was to use Error.pm for
throwing errors; I'm not a Perl hacker, so I cannot say if this was a
good decision, and if implementation of this part is good.
Using Error.pm is not a bad decision even if more simple mechanisms do the
job.
Lea Wiemann work on Git::Repo and friends was created as object
oriented interface. It was build from ground up instead of reusing
Git.pm to be not encumbered by Git.pm cruft... unfortunately it means
also abandoning all the work that went in Git.pm to make it portable
(read: make it work with crippled ActiveState Perl). You can find
discussion on the design of Git::Repo and decision of it being clean
state implementation at link given by Pasky.
P.S. I have "[RFC] Git Perl bindings, and OO interface" half-written
(well, more like a third), a bit stalled. I'll try to find time to
finish it and send it to git mailing list.
That would be very usefull. the relevant information should be integrated in
the module itself.
Thank you for your input on the history of Git.pm.
Cheers, Nadim
On Sunday 23 November 2008 20.58.11 nadim khemir wrote:
On Thursday 20 November 2008 09.34.46 you wrote:
My current plan is to:
...
- tell my fellow perl developers about this (done, so far very good
response) - confer with the people having git related modules (a few)
- gather ideas for what nededs to be changed (not much this far)
...
This http://perlbuzz.com/2008/12/moving-forward-with-git-and-perl.html should
take care of waking up the perl community (they are not really sleeping just
concentrating on their own perlish world).
In a few days, I'll mail all the developers having git related modules and try
to get a common strategy (wish us luck with that).
Cheers, Nadim.