Re: Git and Google Summer of Code 2012

From: André Walker <andre@andrewalker.net>
Date: Mar 20, 2012, 19:47 UTC
Message-ID: <4F68DEC3.2090006@andrewalker.net>
In-Reply-To: <201203201637.10417.jnareb@gmail.com>

On 03/20/2012 12:37 PM, Jakub Narebski wrote:

Show 6 quoted lines

> Actually the discussion of GSoC project application ideas with mentoring
> organization[1] should take place in the open, on git mailing list,
> git@vger.kernel.org.  (You don't need to be subscribed to send email to
> it, and there is custom on this mailing list of Cc-ing all people
> participating in discussion; you can read git mailing list via other
> interfaces e.g. via GMane.)

Right, thanks for pointing it out. Either way (doing GSoC or not), it'll be cool to join the list.

Show 6 quoted lines

>  From what I understand "Linus's ultimate content tracking tool" is
> rather a sketch of an idea, rather than concrete project proposal.
> You would have to carve a project from this proposal yourself.
> ...
> People on git mailing list could help there, perhaps starting with
> person that suggested it.

Thanks, I'm still thinking about it. I'll read with more time the e-mail in which Linus proposed the idea, and then I'll decide whether to look more into it (mail him, etc).

Show 18 quoted lines

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

>> Also, why is it not on CPAN? Wouldn't it be useful to other people to
>> write interfaces in Perl for Git?
> It is not on CPAN probably because Git Development Community lack(s|ed)
> a Perl hacker, having only Perl dabblers ;-P

Haha, I see :) I hope I can be of some help!

Show 14 quoted lines

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

Show 7 quoted lines

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

Show 7 quoted lines

> You could polish and modernize Git::Object, Git::Commit, Git::Tag,
> Git::Repo and Git::RepoRoot from GSoC 2008 project[2], and add similar
> modules for other concepts: diff (tree level and patchset level), tree
> (directory), refs and refspec, etc.  All those with tests.
>
> [2]: git://repo.or.cz/git/gitweb-caching.git
>       http://repo.or.cz/w/git/gitweb-caching.git (gitweb)

Right, thanks, I'm taking a look at that too.

Show 14 quoted lines

> You could separate somehow the idea of git commands that do not
> require repository like "git version" or "git config --file", or
> "git init" (Git::Cmd?), those that require repository but not working
> area like "git log" or "git show" (Git::Repo?), and those that require
> working area like "git status" or "git pull" (Git::Repo::Workdir?).
>
> You could, for example based on existing gitweb code, create Git::Config
> module that would read all configuration at once with `git config -l`,
> and not use one git command for one variable like current $git->config()
> does.
>
> You could create interfaces to persistent "git cat-file --batch",
> "git cat-file --batch-check" and "git diff-tree --stdin".  IIRC gsoc2008
> project includes something like that.

Sounds reasonable. Though some parts I still have to take a look at the code to understand better.

> And of course borrow^W steal interesting parts of Git::* modules
> available on CPAN.

Seems the best way to go :)

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

> HTH

It does, thank you very much!

Cheers, André.