On Tue, 20 Mar 2012, André Walker wrote:
Hello Jakub, I tweeted to you, but as your last tweet was from January, I'm
guessing here [personal email via Google Profile] is probably a better
place to talk.
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.)
Perhaps this should be stated more clearly, for example in application
template[2].
[1]: http://www.google-melange.com/gsoc/events/google/gsoc2012
[2]: https://github.com/peff/git/wiki/SoC-2012-Template
I'm a Computer Science student from a Brazilian university, and I
have participated in GSoC last year with The Perl Foundation.
I reworked the Catalyst MVC framework to use an Inversion of Control
framework called Bread::Board instead of it's home grown component
loading system. I was supposed to continue my work on it this year,
we were going to release Catalyst v6.0 with it, but TPF was not
accepted in GSoC. I guess we'll have to ship it without GSoC then.
Anyhow, I'd like to participate in it again this year, even if not
continuing what I began last year. Preferably using Perl, but I guess I
could try something different. And looking in the accepted orgs for GSoC,
Git seemed a very cool option, I'd be very honored to work on it. I use git
on most of my projects, but I have never delved in it's code.
From the ideas page, I got interested in two items: "Modernizing and
expanding Git.pm", and "Linus's ultimate content tracking tool".
To be honest, the latter sounded awesome! But I don't know if I could
be able to pull it off, as I don't know how complex it would be.
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.
I'd be willing to try though, if I could talk to the relevant people,
understand how the implementation would work, etc.
People on git mailing list could help there, perhaps starting with
person that suggested it.
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.
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
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.
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.
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)
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.
And of course borrow^W steal interesting parts of Git::* modules
available on CPAN.
Do you think we could unite both projects, or it would
be too much work? And if you're not the person I should be asking about the
content tracking tool, could you point me to that person?
I think it might be too much work, though prototyping "Linus's ultimate
content tracking tool" in Perl might be good idea...
HTH
--
Jakub Narebski
Poland
On 03/20/2012 12:37 PM, Jakub Narebski wrote:
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.
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).
quoted
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.
quoted
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!
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.
quoted
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?
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.
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é.
On Tue, 30 Mar 2012, André Walker wrote:
On 03/20/2012 12:37 PM, Jakub Narebski wrote:
quoted
André Walker wrote:
quoted
quoted
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.
[...]
quoted
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.
quoted
quoted
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.
[...]
quoted
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