Statictics on Git.pm usage in git commands (was: [PATCH 2/3] add new Git::Repo API)
From: Jakub Narebski <hidden>
Date: 2016-06-15 22:44:58
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