Git(3) User Contributed Perl Documentation Git(3)NAMEGit - Perl interface to the Git version control system
SYNOPSIS
use Git;
my $version = Git::command_oneline('version');
git_cmd_try { Git::command_noisy('update-server-info') }
'%s failed w/ code %d';
my $repo = Git->repository (Directory => '/srv/git/cogito.git');
my @revs = $repo->command('rev-list', '--since=last monday', '--all');
my ($fh, $c) = $repo->command_output_pipe('rev-list', '--since=last monday', '--all');
my $lastrev = <$fh>; chomp $lastrev;
$repo->command_close_pipe($fh, $c);
my $lastrev = $repo->command_oneline( [ 'rev-list', '--all' ],
STDERR => 0 );
DESCRIPTION
This module provides Perl scripts easy way to interface the Git version
control system. The modules have an easy and well-tested way to call
arbitrary Git commands; in the future, the interface will also provide
specialized methods for doing easily operations which are not totally
trivial to do over the generic command interface.
While some commands can be executed outside of any context (e.g. 'ver‐
sion' or 'init'), most operations require a repository context, which
in practice means getting an instance of the Git object using the
repository() constructor. (In the future, we will also get a
new_repository() constructor.) All commands called as methods of the
object are then executed in the context of the repository.
Part of the "repository state" is also information about path to the
attached working copy (unless you work with a bare repository). You can
also navigate inside of the working copy using the "wc_chdir()" method.
(Note that the repository object is self-contained and will not change
working directory of your process.)
TODO: In the future, we might also do
my $remoterepo = $repo->remote_repository (Name => 'cogito', Branch => 'master');
$remoterepo ⎪⎪= Git->remote_repository ('http://git.or.cz/cogito.git/');
my @refs = $remoterepo->refs();
Currently, the module merely wraps calls to external Git tools. In the
future, it will provide a much faster way to interact with Git by link‐
ing directly to libgit. This should be completely opaque to the user,
though (performance increate nonwithstanding).
CONSTRUCTORS
repository ( OPTIONS )
repository ( DIRECTORY )
repository ()
Construct a new repository object. "OPTIONS" are passed in a hash
like fashion, using key and value pairs. Possible options are:
Repository - Path to the Git repository.
WorkingCopy - Path to the associated working copy; not strictly
required as many commands will happily crunch on a bare repository.
WorkingSubdir - Subdirectory in the working copy to work inside.
Just left undefined if you do not want to limit the scope of opera‐
tions.
Directory - Path to the Git working directory in its usual setup.
The ".git" directory is searched in the directory and all the par‐
ent directories; if found, "WorkingCopy" is set to the directory
containing it and "Repository" to the ".git" directory itself. If
no ".git" directory was found, the "Directory" is assumed to be a
bare repository, "Repository" is set to point at it and "Working‐
Copy" is left undefined. If the $GIT_DIR environment variable is
set, things behave as expected as well.
You should not use both "Directory" and either of "Repository" and
"WorkingCopy" - the results of that are undefined.
Alternatively, a directory path may be passed as a single scalar
argument to the constructor; it is equivalent to setting only the
"Directory" option field.
Calling the constructor with no options whatsoever is equivalent to
calling it with "Directory => '.'". In general, if you are building
a standard porcelain command, simply doing "Git->repository()"
should do the right thing and setup the object to reflect exactly
where the user is right now.
METHODS
command ( COMMAND [, ARGUMENTS... ] )
command ( [ COMMAND, ARGUMENTS... ], { Opt => Val ... } )
Execute the given Git "COMMAND" (specify it without the 'git-' pre‐
fix), optionally with the specified extra "ARGUMENTS".
The second more elaborate form can be used if you want to further
adjust the command execution. Currently, only one option is sup‐
ported:
STDERR - How to deal with the command's error output. By default
("undef") it is delivered to the caller's "STDERR". A false value
(0 or '') will cause it to be thrown away. If you want to process
it, you can get it in a filehandle you specify, but you must be
extremely careful; if the error output is not very short and you
want to read it in the same process as where you called "com‐
mand()", you are set up for a nice deadlock!
The method can be called without any instance or on a specified Git
repository (in that case the command will be run in the repository
context).
In scalar context, it returns all the command output in a single
string (verbatim).
In array context, it returns an array containing lines printed to
the command's stdout (without trailing newlines).
In both cases, the command's stdin and stderr are the same as the
caller's.
command_oneline ( COMMAND [, ARGUMENTS... ] )
command_oneline ( [ COMMAND, ARGUMENTS... ], { Opt => Val ... } )
Execute the given "COMMAND" in the same way as command() does but
always return a scalar string containing the first line of the com‐
mand's standard output.
command_output_pipe ( COMMAND [, ARGUMENTS... ] )
command_output_pipe ( [ COMMAND, ARGUMENTS... ], { Opt => Val ... } )
Execute the given "COMMAND" in the same way as command() does but
return a pipe filehandle from which the command output can be read.
The function can return "($pipe, $ctx)" in array context. See
"command_close_pipe()" for details.
command_input_pipe ( COMMAND [, ARGUMENTS... ] )
command_input_pipe ( [ COMMAND, ARGUMENTS... ], { Opt => Val ... } )
Execute the given "COMMAND" in the same way as command_out‐
put_pipe() does but return an input pipe filehandle instead; the
command output is not captured.
The function can return "($pipe, $ctx)" in array context. See
"command_close_pipe()" for details.
command_close_pipe ( PIPE [, CTX ] )
Close the "PIPE" as returned from "command_*_pipe()", checking
whether the command finished successfully. The optional "CTX" argu‐
ment is required if you want to see the command name in the error
message, and it is the second value returned by "command_*_pipe()"
when called in array context. The call idiom is:
my ($fh, $ctx) = $r->command_output_pipe('status');
while (<$fh>) { ... }
$r->command_close_pipe($fh, $ctx);
Note that you should not rely on whatever actually is in "CTX";
currently it is simply the command name but in future the context
might have more complicated structure.
command_noisy ( COMMAND [, ARGUMENTS... ] )
Execute the given "COMMAND" in the same way as command() does but
do not capture the command output - the standard output is not
redirected and goes to the standard output of the caller applica‐
tion.
While the method is called command_noisy(), you might want to as
well use it for the most silent Git commands which you know will
never pollute your stdout but you want to avoid the overhead of the
pipe setup when calling them.
The function returns only after the command has finished running.
version ()
Return the Git version in use.
exec_path ()
Return path to the Git sub-command executables (the same as "git
--exec-path"). Useful mostly only internally.
repo_path ()
Return path to the git repository. Must be called on a repository
instance.
wc_path ()
Return path to the working copy. Must be called on a repository
instance.
wc_subdir ()
Return path to the subdirectory inside of a working copy. Must be
called on a repository instance.
wc_chdir ( SUBDIR )
Change the working copy subdirectory to work within. The "SUBDIR"
is relative to the working copy root directory (not the current
subdirectory). Must be called on a repository instance attached to
a working copy and the directory must exist.
config ( VARIABLE )
Retrieve the configuration "VARIABLE" in the same manner as "con‐
fig" does. In scalar context requires the variable to be set only
one time (exception is thrown otherwise), in array context returns
allows the variable to be set multiple times and returns all the
values.
Must be called on a repository instance.
This currently wraps command('config') so it is not so fast.
config_bool ( VARIABLE )
Retrieve the bool configuration "VARIABLE". The return value is
usable as a boolean in perl (and "undef" if it's not defined, of
course).
Must be called on a repository instance.
This currently wraps command('config') so it is not so fast.
config_int ( VARIABLE )
Retrieve the integer configuration "VARIABLE". The return value is
simple decimal number. An optional value suffix of 'k', 'm', or
'g' in the config file will cause the value to be multiplied by
1024, 1048576 (1024^2), or 1073741824 (1024^3) prior to output. It
would return "undef" if configuration variable is not defined,
Must be called on a repository instance.
This currently wraps command('config') so it is not so fast.
get_colorbool ( NAME )
Finds if color should be used for NAMEd operation from the configu‐
ration, and returns boolean (true for "use color", false for "do
not use color").
get_color ( SLOT, COLOR )
Finds color for SLOT from the configuration, while defaulting to
COLOR, and returns the ANSI color escape sequence:
print $repo->get_color("color.interactive.prompt", "underline blue white");
print "some text";
print $repo->get_color("", "normal");
ident ( TYPE ⎪ IDENTSTR )
ident_person ( TYPE ⎪ IDENTSTR ⎪ IDENTARRAY )
This suite of functions retrieves and parses ident information, as
stored in the commit and tag objects or produced by "var
GIT_type_IDENT" (thus "TYPE" can be either author or committer;
case is insignificant).
The "ident" method retrieves the ident information from "git-var"
and either returns it as a scalar string or as an array with the
fields parsed. Alternatively, it can take a prepared ident string
(e.g. from the commit object) and just parse it.
"ident_person" returns the person part of the ident - name and
email; it can take the same arguments as "ident" or the array
returned by "ident".
The synopsis is like:
my ($name, $email, $time_tz) = ident('author');
"$name <$email>" eq ident_person('author');
"$name <$email>" eq ident_person($name);
$time_tz =~ /^\d+ [+-]\d{4}$/;
Both methods must be called on a repository instance.
hash_object ( TYPE, FILENAME )
Compute the SHA1 object id of the given "FILENAME" (or data waiting
in "FILEHANDLE") considering it is of the "TYPE" object type
("blob", "commit", "tree").
The method can be called without any instance or on a specified Git
repository, it makes zero difference.
The function returns the SHA1 hash.
ERROR HANDLING
All functions are supposed to throw Perl exceptions in case of errors.
See the Error module on how to catch those. Most exceptions are mere
Error::Simple instances.
However, the "command()", "command_oneline()" and "command_noisy()"
functions suite can throw "Git::Error::Command" exceptions as well:
those are thrown when the external command returns an error code and
contain the error code as well as access to the captured command's out‐
put. The exception class provides the usual "stringify" and "value"
(command's exit code) methods and in addition also a "cmd_output"
method that returns either an array or a string with the captured com‐
mand output (depending on the original function call context; "com‐
mand_noisy()" returns "undef") and $<cmdline> which returns the command
and its arguments (but without proper quoting).
Note that the "command_*_pipe()" functions cannot throw this exception
since it has no idea whether the command failed or not. You will only
find out at the time you "close" the pipe; if you want to have that
automated, use "command_close_pipe()", which can throw the exception.
git_cmd_try { CODE } ERRMSG
This magical statement will automatically catch any
"Git::Error::Command" exceptions thrown by "CODE" and make your
program die with "ERRMSG" on its lips; the message will have %s
substituted for the command line and %d for the exit status. This
statement is useful mostly for producing more user-friendly error
messages.
In case of no exception caught the statement returns "CODE"'s
return value.
Note that this is the only auto-exported function.
COPYRIGHT
Copyright 2006 by Petr Baudis <pasky@suse.cz>.
This module is free software; it may be used, copied, modified and dis‐
tributed under the terms of the GNU General Public Licence, either ver‐
sion 2, or (at your option) any later version.
perl v5.8.8 2008-05-25 Git(3)
