Statictics on Git.pm usage in git commands (was: [PATCH 2/3] add new Git::Repo API)

[Jakub Narebski <jnareb@gmail.com>]

On Fri, 18 July 2008, Petr Baudis wrote:

> But the experience shows that the pipe interface is actually
> the _most_ used part of the Git Perl API.

This made me curious which parts of Git.pm, the current Git Perl API,
are used most.

Here is some statistics on the usage of Git Perl API among built-in
and contrib commands.


>From git commands in Perl the following include "use Git" in their 
sources: git-cvsexportcommit, git-send-email, git-svn, and helper
script git-add--interactive.  There are Perl scripts which do not
use Git.pm: git-archimport (which I think should be obsoleted or
moved to contrib), git-cvsimport, git-cvsserver, git-relink.  This
means that half of Perl scripts use Git Perl API.

The situation is worse for scripts in 'contrib/'.  From those, only
contrib/examples/git-remote.perl uses Git.pm; neither blameview,
continuous, git-import and import-tars in fast-import, setgitperms
and update-paranoid in hooks, stats, nor other Perl scripts in
examples (git-rerere, git-svnimport) include "use Git".

Below there are stats on how different commands from Git.pm are
used in mentioned Perl scripts:

1. git-add--interactive.perl uses Git.pm mainly to access color
   configuration: 2 ->get_colorbool, 8 ->get_color, 1 ->config.
   It also uses once ->repository() constuctor, and once
   ->repo_path().

   This means that future Git::Config _has_ to have support for
   color or colorbool valued configuration values.

2. git-cvsexportcommit.perl uses (besides ->repository() constructor)
   only once ->config; so I guess that current interface wrapping
   git-config should stay, because parsing whole config for such
   situation would be overkill.

   What is strange that git-cvsexportcommit.perl defines its own
   safe_pipe_capture and xargs_safe_pipe_capture (!), and uses
   them, open pipeline, backticks, and system() to call git commands.
   
3. git-send-email.perl uses 5 config, 2 config_bool, 2 ident_person
   (for author and for committer), 1 version, and of course once
   ->repository() constructor.  

   Here we can see how to work around current API to: it uses
   Git::config(@repo, "sendemail.identity") form, where 
   	my $repo = eval { Git->repository() };
   	my @repo = $repo ? ($repo) : ();
   to make it work both with git repository (using repo config), and
   outside/without git repository, using only user and system git
   config.

4. git-svn.perl (which is if I checked correctly third largest scripted
   git command, after gitk-gui/gitk-wish and gitweb/gitweb.perl) uses:

     3  x repository
     28 x command_oneline
     19 x command_noisy
     18 x command
     14 x command_output_pipe
     1  x command_input_pipe
     1  x git_try_cmd  (and many "eval { command()/command_oneline() }")
     2  x cat_blob
     1  x hash_and_insert_object
     1  x get_colorbool

   (The above are all if I have not made mistake when counting commands)

   Side note: git-svn is command which would get most out of
   Git::Config, as it currently uses combination of "git config -l"
   and "git config --get" (I guess that the code in question predates
   machine-parseable "git config -l -z").

Note that all those statictics doesn't count how many times some
Git.pm method was called, only how many times it occurs in the code.

-- 
Jakub Narebski
Poland