view release on metacpan or  search on metacpan

bin/git-gerrit  view on Meta::CPAN

=over

=item B<--update>

This option makes git-gerrit update BRANCH before creating the
change-branch by fetching from Gerrit and fast-forward-merging it with
its remote branch. This way you guarantee to start a change on top of
the newest state of your project, which is usually the right thing to do.

=back

You will be warned if your working area is dirty, as this is sometimes
a mistake.

=head2 git gerrit push OPTIONS*

The C<push> sub-command should be invoked to push a change-branch to
Gerrit's C<refs/for/> branch associated with its upstream branch. It
should be invoked when you have the change-branch checked out in your
working area.

When a new change-branch is pushed it creates a Gerrit change
associated with the TOPIC in its name, as created by C<git gerrit new>
above.

After a successful push, git-gerrit checks out the upstream branch and
deletes the original change-branch. The goal is to maintain a clean
namespace, containing only the change-branches that are being worked
on. When you push one to Gerrit, you don't need to keep it any longer
locally. If you need to amend it later, you'll be able to get to it
with the C<git gerrit checkout> sub-command.

=over

=item B<--keep>

This option tells git-gerrit not to checkout the upstream and not to
delete the change-branch, keeping your working area intact.

=item B<--force>

By default, git-gerrit refuses to push a change-branch unless it
contains a single commit dangling from its upstream and git status is
clean (i.e., C<git status --untracked-files=no> doesn't show any
modification that hasn't been added to the index). If either one of
these conditions don't hold it dies with an error message telling
what's the problem. If you're sure you want to push anyway, you can
use this option. If both conditions don't hold, you'll have to use the
option twice.

It's best to avoid multiple commit pushes, because if you have to
amend them later, having multiple commits may require rebasing
dependent commits, which is a more complex operation and clutters the
review history of the change.

If git status isn't clean, the the upstream isn't checked out.

=item B<--[no]rebase>

Before a brand new change-branch (one ending in a TOPIC C<name>) is
pushed, its upstream branch is updated and it is rebased on top of its
upstream. This is to make sure you're pushing a change based on the
newest project state. If, by any reason, you don't want to have it
rebased, use the C<--norebase> option.

A change-branch that has been checked out (one ending in an ID) isn't
rebased by default, because this would clutter the change review
history in Gerrit. If you want it rebased nonetheless, use the
C<--rebase> option.

If git status isn't clean or if the commit being pushed is a merge
commit it's not rebased.

=item B<--draft>

This option makes git-gerrit push the change-branch to
C<refs/drafts/UPSTREAM> instead of to C<refs/for/UPSTREAM>, creating a
draft change in Gerrit.

=item B<--submit>

This option tells Gerrit to L<auto-merge the change during
push|http://gerrit-documentation.googlecode.com/svn/Documentation/2.7/user-upload.html#auto_merge>,
which is a feature implemented in Gerrit 2.7.

=item B<--base BASE>

This option L<selects a new merge
base|http://gerrit-documentation.googlecode.com/svn/Documentation/2.7/user-upload.html#base>
for Gerrit, which is a feature implemented in Gerrit 2.7.

=item B<--topic TOPIC>

This option specifies another name for the topic that will be
associated with the change. By default, the topic name is the last
component of the current change-branch name, as specified by the C<git
gerrit new> sub-command.

=item B<--reviewer USERS>

This option let's you invite a list of users to review your change.

USERS is a colon-separated list of usernames. You may also pass this
option more than once, to invite more than a set of users.

=item B<--cc USERS>

This option let's you notify a list of users about your change.

USERS is a colon-separated list of usernames. You may also pass this
option more than once, to invite more than a set of users.

=back

=head2 git gerrit query [--limit LIMIT] [--verbose] [[NAME=]QUERY]*

The B<query> sub-command let's you list Gerrit changes meeting
specific criteria. The matching changes are shown in tabular format,
one change per line, listing their legacy ID, status, Code-Review
vote, time of last update, project name, branch name, owner name, and
subject line.

bin/git-gerrit  view on Meta::CPAN

=over

=item B<--limit LIMIT>

This option put a limit on the number of changes that are shown for
each QUERY.

=item B<--verbose>

This option makes the change topic be shown inside parenthesis to the
right of the change branch name. This requires a separate REST call
for each change, making the result appear more slowly.

=back

=head2 git gerrit my [--limit LIMIT] [--verbose] [changes|drafts|watched|starred]

The B<my> sub-command provides a set of pre-defined queries for the
B<query> sub-command. It's based on Gerrit's standard queries shown in
its web interface under the C<My> tab.

The C<changes> argument is used by default if you don't specify any.

The options taken by the C<my> sub-command are passed to the C<query>
sub-command.

=head2 git gerrit show CHANGE*

The B<show> sub-command describes one or more CHANGEs in detail,
showing much like what Gerrit shows in a change page of its web
interface. For example:

    $ git gerrit show 1186
     Change-Num: 1186
      Change-Id: I0bb976fe1890657d7a1c3ba403e0b58ac2b63cd7
        Subject: [SB-1] Test amend 3
          Owner: Gustavo Chaves
        Project: helloworld
         Branch: master
        Created: 2013-09-18 16:22:21
        Updated: 2013-09-18 19:45:56
         Status: MERGED

    REVIEWER                         Code-Review
    Gustavo Leite de Mendonça Chaves  0
    Jenkins                          +1
    Laurel Keys                      +2
    ------------------------------------------------------------

If no CHANGE is specified, the one associated with the current
change-branch is described. If you're not in a change-branch, you'll
get an error.

=head2 git gerrit fetch CHANGE*

The B<fetch> sub-command fetches one or more CHANGEs from Gerrit and
creates change-branches pointing to them.

A Gerrit change may contain a series of patch-sets. The C<fetch>
sub-command fetches the current (latest) one. If there is already a
change-branch for the change, it will be updated to the change's
current patch-set.

If you omit the CHANGE argument and you are in a change-branch, it
will be updated with its current patch-set.

=head2 git gerrit checkout CHANGE*

The B<checkout> sub-command fetches one or more CHANGEs from Gerrit,
creates change-branches pointing to them, and checks out the last
one. It's like invoking B<git gerrit fetch CHANGE> and then B<git
checkout CHANGE-BRANCH>.

The shorter name C<co> can also be used instead of C<checkout>.

=head2 git gerrit upstream [--keep] [--delete]

The B<upstream> sub-command should be invoked when you're in a
change-branch. It checks out the upstream branch and deletes the
change-branch if it's associated with an already pushed change, i.e.,
if its name ends in a legacy numeric id, not in a topic name.

The shorter name C<up> can also be used instead of C<upstream>.

=over

=item B<--keep>

This option prevents the change-branch deletion after the upstream
checkout.

=item B<--delete>

This options forces the change-branch deletion when it's a new
change. However, the <--keep> option has precedence, meaning that if
both options are present the change-branch isn't deleted.

=back

=head2 git gerrit cherry-pick [--edit] [--no-commit] CHANGE*

The B<cherry-pick> sub-command invokes the B<fetch> sub-command to
fetch a list of CHANGES from Gerrit and to create local
change-branches for them. Then it applies all those changes to the
current branch using the C<git cherry-pick> command.

You may want to use this command to work on top of changes not
submitted in Gerrit yet. You can cherry-pick them on top of a scratch
branch and then continue to work on top of it while you wait for those
changes to be reviewed.

The shorter name C<cp> can also be used instead of C<cherry-pick>.

=over

=item B<--edit>

If specified, this option is passed to C<git cherry-pick> to let you
edit the commit message.

=item B<--no-commit>

If specified, this option is passed to C<git cherry-pick> to avoid
performing any commits.