NAME¶
Git - 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 );
my $sha1 = $repo->hash_and_insert_object('file.txt');
my $tempfile = tempfile();
my $size = $repo->cat_blob($sha1, $tempfile);
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. 'version' 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 linking directly to
libgit. This should be completely opaque to the user, though (performance
increase notwithstanding).
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 operations.
Directory - Path to the Git working directory in its usual setup.
The ".git" directory is searched in the directory and all the
parent 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 "WorkingCopy"
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-' prefix), 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 supported:
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 "command()", 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 command'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_output_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" argument 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_bidi_pipe ( COMMAND [, ARGUMENTS... ] )
- Execute the given "COMMAND" in the same way as
command_output_pipe() does but return both an input pipe filehandle
and an output pipe filehandle.
The function will return return "($pid, $pipe_in, $pipe_out,
$ctx)". See "command_close_bidi_pipe()" for details.
- command_close_bidi_pipe ( PID, PIPE_IN, PIPE_OUT [, CTX]
)
- Close the "PIPE_IN" and "PIPE_OUT" as
returned from "command_bidi_pipe()", checking whether the
command finished successfully. The optional "CTX" argument is
required if you want to see the command name in the error message, and it
is the fourth value returned by "command_bidi_pipe()". The call
idiom is:
my ($pid, $in, $out, $ctx) = $r->command_bidi_pipe('cat-file --batch-check');
print "000000000\n" $out;
while (<$in>) { ... }
$r->command_close_bidi_pipe($pid, $in, $out, $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
application.
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.
- html_path ()
- Return path to the Git html documentation (the same as
"git --html-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 "config" 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.
- 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).
- config_path ( VARIABLE )
- Retrieve the path configuration "VARIABLE". The
return value is an expanded path or "undef" if it's not
defined.
- 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,
- get_colorbool ( NAME )
- Finds if color should be used for NAMEd operation from the
configuration, 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");
- remote_refs ( REPOSITORY [, GROUPS [, REFGLOBS ] ] )
- This function returns a hashref of refs stored in a given
remote repository. The hash is in the format "refname =\"
hash>. For tags, the "refname" entry contains the tag object
while a "refname^{}" entry gives the tagged objects.
"REPOSITORY" has the same meaning as the appropriate
"git-ls-remote" argument; either a URL or a remote name (if
called on a repository instance). "GROUPS" is an optional
arrayref that can contain 'tags' to return all the tags and/or 'heads' to
return all the heads. "REFGLOB" is an optional array of strings
containing a shell-like glob to further limit the refs returned in the
hash; the meaning is again the same as the appropriate
"git-ls-remote" argument.
This function may or may not be called on a repository instance. In the
former case, remote names as defined in the repository are recognized as
repository specifiers.
- 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}$/;
- hash_object ( TYPE, FILENAME )
- Compute the SHA1 object id of the given
"FILENAME" 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.
- hash_and_insert_object ( FILENAME )
- Compute the SHA1 object id of the given
"FILENAME" and add the object to the object database.
The function returns the SHA1 hash.
- cat_blob ( SHA1, FILEHANDLE )
- Prints the contents of the blob identified by
"SHA1" to "FILEHANDLE" and returns the number of bytes
printed.
- temp_acquire ( NAME )
- Attempts to retreive the temporary file mapped to the
string "NAME". If an associated temp file has not been created
this session or was closed, it is created, cached, and set for autoflush
and binmode.
Internally locks the file mapped to "NAME". This lock must be
released with "temp_release()" when the temp file is no longer
needed. Subsequent attempts to retrieve temporary files mapped to the same
"NAME" while still locked will cause an error. This locking
mechanism provides a weak guarantee and is not threadsafe. It does provide
some error checking to help prevent temp file refs writing over one
another.
In general, the File::Handle returned should not be closed by consumers as
it defeats the purpose of this caching mechanism. If you need to close the
temp file handle, then you should use File::Temp or another temp file
faculty directly. If a handle is closed and then requested again, then a
warning will issue.
- temp_release ( NAME )
- temp_release ( FILEHANDLE )
- Releases a lock acquired through
"temp_acquire()". Can be called either with the "NAME"
mapping used when acquiring the temp file or with the
"FILEHANDLE" referencing a locked temp file.
Warns if an attempt is made to release a file that is not locked.
The temp file will be truncated before being released. This can help to
reduce disk I/O where the system is smart enough to detect the truncation
while data is in the output buffers. Beware that after the temp file is
released and truncated, any operations on that file may fail miserably
until it is re-acquired. All contents are lost between each release and
acquire mapped to the same string.
- temp_reset ( FILEHANDLE )
- Truncates and resets the position of the
"FILEHANDLE".
- temp_path ( NAME )
- temp_path ( FILEHANDLE )
- Returns the filename associated with the given
tempfile.
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 output. 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 command output (depending on the
original function call context; "command_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 distributed
under the terms of the GNU General Public Licence, either version 2, or (at
your option) any later version.