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 -- 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