view release on metacpan or  search on metacpan

bin/git-gerrit  view on Meta::CPAN

invited as reviewers in a B<git gerrit push> command.

USERS is a colon-separated list of usernames.

CONDITIONs are space-separated boolean expressions. All CONDITIONs, if
any, must be true for USERS to be invited. If no CONDITIONS are
specified, USERS are invited.

A CONDITION may check either the name of the branch to which the
change is being pushed or the names of the files affected by the
change itself. The matching may be either exact or by L<regular
expressions|perlre>, as follows.

=over

=item * branch=REFNAME

Checks if REFNAME is exactly equal to the change's upstream name
(without the C<refs/heads> prefix).

=item * branch~REGEXP

Checks if the upstream name matches REGEXP.

=item * path=PATH

Checks if the path of any file affected by the commit being pushed, as
shown by C<git diff --name-only upstream..HEAD> is exactly equal to
the complete path of one of those files.

=item * path~REGEXP

Checks if the path of any affected file matches REGEXP.

=back

You may specify the C<git-gerrit.reviewers> variable multiple
times. All users mentioned in all specifications that match their
CONDITIONs are invited as reviewers to the current change being
pushed.

=back

=head1 COMMIT-MSG HOOK

Gerrit provides a C<commit-msg> hook for Git that should be installed
in your repositories. Its purpose is to insert a C<Change-Id> footer
in the commit messages so that Gerrit can discern independent commits
from merely amended ones.

Git-gerrit takes care of installing this hook for you. When you invoke
its C<new> or C<push> sub-commands, it checks to see if your
repository already has a C<commit-msg> hook installed. If not, it
automatically downloads Gerrit's standard hook and installs it for
you.

=head1 AUTHENTICATION

If you have Git 1.8.0 or later, git-gerrit uses Git's credential
management system via its B<git-credential> command to obtain
credentials for connecting to Gerrit. You can take advantage of this
by configuring Git's C<credential.helper> variable to use a persistent
credential storage and avoid being asked for the authentication
credentials repeatedly. Please, read B<gitcredentials> manpage to know
how to configure this system. But here are a few tips anyway:

=over

=item * B<On Ubuntu Linux (tested on 13.04)>

Use the
L<git-credential-gnome-keyring|http://stackoverflow.com/questions/13385690/how-to-use-git-with-gnome-keyring-integration>
program which provides a very nice integration with your desktop
environment. You have to compile the helper first:

    sudo apt-get install libgnome-keyring-dev
    sudo make -C /usr/share/doc/git/contrib/credential/gnome-keyring
    git config --global credential.helper /usr/share/doc/git/contrib/credential/gnome-keyring/git-credential-gnome-keyring

=item * B<On other Unix-like systems>

The B<git-credential-cache> command which comes with Git is as a
balanced compromise between convenience and security:

    git config --global credential.helper cache --timeout 86400

=item * B<On Windows systems>

The best choice seems to be the third-party application
L<git-credential-winstore|http://gitcredentialstore.codeplex.com/>,
which you have to install first.

    git config --global credential.helper winstore

=back

If you're using a pre-1.8 Git that doesn't support the
B<git-credential> command, there are a few fall-backs.

First, git-gerrit tries to get credentials from the
C<git-gerrit.baseurl> configuration variable. The URL should be in a
format like C<https://username:password@host/path>. Security conscious
people should avoid putting credentials there, but if you do
git-gerrit will be satisfied.

Then, git-gerrit tries to load Perl's L<Net::Netrc> module, if
available, to get credentials from a C<netrc(5)> file.

As a last resort, git-gerrit tries to load Perl's L<Term::Prompt>
module to prompt you for the credentials.

If none of this works, git-gerrit dies screaming.

=head1 BASH COMPLETION

If you use bash and have L<bash completion enabled for
Git|http://git-scm.com/book/en/Git-Basics-Tips-and-Tricks> you may
also enable it for git-gerrit by sourcing the
F<etc/bash_completion.d/git-gerrit> script that comes with
L<App::GitGerrit> distribution. You may do it in your F<~/.bashrc>
file like this:

    source $PERL_ROOT/etc/bash_completion.d/git-gerrit

Where C<PERL_ROOT> is the root of your Perl installation.

=head1 SEE ALSO

There are some alternatives to git-gerrit, other Git extensions to
make it easier to interact with Gerrit. The three mentioned below are
the most well known. All of them use Gerrit's mature and simple SSH
API while git-gerrit's distinguishes from them in that it uses
Gerrit's newer and more comprehensive REST API.

=over

=item * L<git-review|https://github.com/openstack-infra/git-review>

Being the original inspiration for git-gerrit, git-review is a mature
tool that's used by some very well known projects, such as OpenStack,
MediaWiki, and LibreOffice.

=item * L<git-change|https://github.com/Nextdoor/git-change>

Simpler than git-review, git-change is better documented and has the
best name of all. From it, git-gerrit took the change-branch concept.

=item * L<querrit|https://gitorious.org/querrit/querrit>

A very simple tool to query Gerrit and make it easier to push changes.

=back

If you're interested in Gerrit automation per se, you can take a look
at the L<Gerrit::REST> Perl module, which is used by C<git-gerrit> to
interact with Gerrit via it's REST API.

=head1 AUTHOR

Gustavo L. de M. Chaves <gnustavo@cpan.org>

=head1 COPYRIGHT AND LICENSE

This software is copyright (c) 2013 by CPqD <www.cpqd.com.br>.

This is free software; you can redistribute it and/or modify it under
the same terms as the Perl 5 programming language system itself.

=cut