Re: Git and Google Summer of Code 2012

[Jakub Narebski <jnareb@gmail.com>]

On Tue, 30 Mar 2012, André Walker wrote:
> On 03/20/2012 12:37 PM, Jakub Narebski wrote:
> > André Walker wrote:

> > > And, well, in the first one (Modernizing Git.pm) they pointed
> > > you as a possible mentor, so I'd like to know. First, how much of Git is
> > > actually in Perl? In other words, how much of it is implemented in Git.pm
> > > and related modules, or who would use it exactly?
> >
> > There are quite a few git commands implemented in Perl, and there were
> > even more before "builtin-ification" of git code (moving to C).  Those
> > include the interactive part of git-add (git-add--interactive helper),
> > git-cvsimport, git-cvsserver and git-svn, git-send-email, git-difftool
> > and gitweb.  Not all of those use Git.pm module (git-cvsimport,
> > git-cvsserver and gitweb do not); changing this might be part of GSoC
> > project.
> >
> > Git.pm currently does mainly cover safe and portable (ActiveState Perl)
> > invoking of git commands, and a bit of converting / translating
> > output to Perl (e.g. config_bool() method).
> >
> > It is by no means complete; some of code could be refactored and moved
> > from individual commands to Git.pm module.
>
> Got it. I'm cloning git's code to help visualize it better.
[...] 
> > More seriously, putting Git.pm on CPAN might be a part of this GSoC
> > project.  Not that CPAN lacks git modules: Git::Class, Git::PurePerl,
> > Git::Repository, Git::Wrapper, Git::XS (libgit2 based)...
> >
> > Note however that Git.pm must (in my opinion) remain "dual lived" module,
> > i.e. reside in git.git repository and be installable alongside git
> > with nothing but git sources.  This also means that any extra non-core
> > (or even not installed by default with "perl" package) modules that
> > Git.pm requires to work need to have copy in git.git repository just
> > like private-Error.pm (should be 'inc/Error.pm') does currently.
> >
> > Git.pm might ultimately be put in separate repository, and subtree-merged
> > into git.git like git-gui and gitk subsystems (or as submodule), but that
> > would require having real maintainer for this module.
>
> Right. Yeah, in a quick look on CPAN I saw those. I understand what you 
> mean that it should remain dual lived. Is using local::lib a viable 
> option? It would make it much easier to keep everything updated, and 
> have new required modules, etc. Though I guess that's something that 
> could be decided during development.

local::lib is a good solution (which probably didn't exist at the time
of writing Git.pm and putting private-Error.pm in 'perl/' subdirectory.
Whether it is good enough, or should we put required non-core Perl
modules in 'inc/' to be able to install them with Git.pm...
 
Anyway it could be decided at merge time.

> > > It mentions replacing Error and Error::Simple for Try::Tiny and
> > > Exception::Class. What else should be modernized? And where else is there
> > > room for expansion?
> >
> > You could borrow from IPC::Run, Capture::Tiny and similar modules to make
> > it possible to capture stderr of git commands to separate string or
> > separate filehandle, or just silencing stderr completely.  Perhaps even
> > allowing creating pipelines.
>
> I don't really understand what you mean by this. I should capture stderr 
> for Git.pm, or other git commands? And why would I do that? Is it to 
> manually get errors instead of Try::Tiny?

Git commands might print some messages to stderr, even in the case where
result is not considered an error (e.g. "git rev-parse --verify", or
"git cat-file -t").  Gitweb uses string form of 'exec' (well, 'open "-|"'
to be more exact) with " 2>/dev/null" to silence warnings.  I'd like
to be able to silence stderr, or capture it (like command_oneline() etc.
capture stdout) with something like existing command_* commands.
 
[...]
> > I think it might be too much work, though prototyping "Linus's ultimate
> > content tracking tool" in Perl might be good idea...
>
> Yeah, now that you explained better, it's really too much work for GSoC. 
> I'd better be realistic and pick one. Probably the Git.pm one is more 
> realistic and could be used afterwards by "Linus's ultimate content 
> tracking tool", if it's ever made in Perl.

Well, there is a question how many project will be funded by Google...
-- 
Jakub Narebski
Poland