App-GitGerrit

 view release on metacpan or  search on metacpan

bin/git-gerrit  view on Meta::CPAN

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

bin/git-gerrit  view on Meta::CPAN

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>.

lib/App/GitGerrit.pm  view on Meta::CPAN

    my $changes = query_changes(@queries);

    for (my $i=0; $i < @$changes; ++$i) {
        print "[$names[$i]=$queries[$i]]\n";
        next unless @{$changes->[$i]};

        require Text::Table;
        my $table = Text::Table->new("ID\n&num", qw/STATUS CR UPDATED PROJECT BRANCH OWNER SUBJECT/);

        foreach my $change (sort {$b->{updated} cmp $a->{updated}} @{$changes->[$i]}) {
            if ($Options{verbose}) {
                if (my $topic = gerrit_or_die(GET => "/changes/$change->{id}/topic")) {
                    $change->{branch} .= " ($topic)";
                }
            }
            $table->add(
                $change->{_number},
                $change->{status},
                code_review($change->{labels}{'Code-Review'}),
                normalize_date($change->{updated}),
                $change->{project},
                $change->{branch},
                $change->{owner}{name},
                $change->{subject},
            );
        }
        print $table->table(), "\n";
    }

    return;

lib/App/GitGerrit.pm  view on Meta::CPAN

    foreach my $id (@ARGV) {
        my $change = gerrit_or_die(GET => "/changes/$id/detail");

        print <<EOF;
 Change-Num: $change->{_number}
  Change-Id: $change->{change_id}
    Subject: $change->{subject}
      Owner: $change->{owner}{name}
EOF

        foreach my $date (qw/created updated/) {
            $change->{$date} = normalize_date($change->{$date})
                if exists $change->{$date};
        }

        foreach my $key (qw/project branch topic created updated status reviewed mergeable/) {
            printf "%12s %s\n", "\u$key:", $change->{$key}
                if exists $change->{$key};
        }

        print "\n";
        # We want to produce a table in which the first column lists the
        # reviewer names and the other columns have their votes for each
        # label. However, the change object has this information
        # inverted. So, we have to first collect all votes.
        my @labels = sort keys %{$change->{labels}};