| Git(3) | User Contributed Perl Documentation | Git(3) |
Git - Perl interface to the Git version control system
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);
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).
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.
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.
The function can return "($pipe, $ctx)" in array context. See "command_close_pipe()" for details.
The function can return "($pipe, $ctx)" in array context. See "command_close_pipe()" for details.
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.
The function will return "($pid, $pipe_in, $pipe_out, $ctx)". See "command_close_bidi_pipe()" for details.
my ($pid, $in, $out, $ctx) = $r->command_bidi_pipe('cat-file --batch-check');
print $out "000000000\n";
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.
"PIPE_IN" and "PIPE_OUT" may be "undef" if they have been closed prior to calling this function. This may be useful in a query-response type of commands where caller first writes a query and later reads response, eg:
my ($pid, $in, $out, $ctx) = $r->command_bidi_pipe('cat-file --batch-check');
print $out "000000000\n";
close $out;
while (<$in>) { ... }
$r->command_close_bidi_pipe($pid, $in, undef, $ctx);
This idiom may prevent potential dead locks caused by data sent to the output pipe not being flushed and thus not reaching the executed command.
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.
If TIME is not supplied, the current local time is used.
Honours GIT_ASKPASS and SSH_ASKPASS environment variables for querying the user. If no *_ASKPASS variable is set or an error occoured, the terminal is tried as a fallback. If "ISPASSWORD" is set and true, the terminal disables echo.
print $repo->get_color("color.interactive.prompt", "underline blue white");
print "some text";
print $repo->get_color("", "normal");
"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.
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}$/;
The method can be called without any instance or on a specified Git repository, it makes zero difference.
The function returns the SHA1 hash.
The function returns the SHA1 hash.
If 'url' key exists it will be written first. (All the other key-value pairs are written in sorted order but you should not depend on that). Once all lines are written, an empty line is printed.
In the first form, "OPERATION" can be 'fill', 'approve' or 'reject', and function will execute corresponding "git credential" sub-command. If it's omitted 'fill' is assumed. In case of 'fill' the values stored in "CREDENTIAL_HASHREF" will be changed to the ones returned by the "git credential fill" command. The usual usage would look something like:
my %cred = (
'protocol' => 'https',
'host' => 'example.com',
'username' => 'bob'
);
Git::credential \%cred;
if (try_to_authenticate($cred{'username'}, $cred{'password'})) {
Git::credential \%cred, 'approve';
... do more stuff ...
} else {
Git::credential \%cred, 'reject';
}
In the second form, "CODE" needs to be a reference to a subroutine. The function will execute "git credential fill" to fill the provided credential hash, then call "CODE" with "CREDENTIAL_HASHREF" as the sole argument. If "CODE"'s return value is defined, the function will execute "git credential approve" (if return value yields true) or "git credential reject" (if return value is false). If the return value is undef, nothing at all is executed; this is useful, for example, if the credential could neither be verified nor rejected due to an unrelated network error. The return value is the same as what "CODE" returns. With this form, the usage might look as follows:
if (Git::credential {
'protocol' => 'https',
'host' => 'example.com',
'username' => 'bob'
}, sub {
my $cred = shift;
return !!try_to_authenticate($cred->{'username'},
$cred->{'password'});
}) {
... do more stuff ...
}
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.
When temp_acquire is called on a "NAME", it internally locks the temporary file mapped to "NAME". That lock will not be released until "temp_release()" is called with either the original "NAME" or the File::Handle that was returned from the original call to temp_acquire.
Subsequent attempts to call "temp_acquire()" with the same "NAME" will fail unless there has been an intervening "temp_release()" call for that "NAME" (or its corresponding File::Handle that was returned by the original "temp_acquire()" call).
If true is returned by "temp_is_locked()" for a "NAME", an attempt to "temp_acquire()" the same "NAME" will cause an error unless "temp_release" is first called on that "NAME" (or its corresponding File::Handle that was returned by the original "temp_acquire()" call).
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.
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.
In case of no exception caught the statement returns "CODE"'s return value.
Note that this is the only auto-exported function.
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.
| 2020-04-20 | perl v5.28.1 |