Gerrit command line tools

[Garret]

Hi,

I found this command

http://gerrit.googlecode.com/svn/documentation/2.0/cmd-approve.html

quite handy and was wondering if there was something similar to
actually commit/publish the change sets in Gerrit to git? I know it's
possible to bypass Gerrit completely and push directly to git, but
we'd like our commits to still be reviewable in Gerrit.

Also, I'm not sure if it's just coincidence, but when I run a command
like this:

$ ssh -p 29418 review.example.com gerrit approve \
--verified=+1 \
--code-review=+2 \
--project=this/project \
$(git rev-list origin/master..HEAD)

Gerrit seems to hang or lock-up. Not sure if there have been outages
today.

thanks,
Garret

[Shawn Pearce]

On Mon, Aug 31, 2009 at 14:26, Garret<pic...@pv.com> wrote:
> I found this command
>
> http://gerrit.googlecode.com/svn/documentation/2.0/cmd-approve.html
>
> quite handy and was wondering if there was something similar to
> actually commit/publish the change sets in Gerrit to git?

What do you mean, publish the change sets in Gerrit to git? Every
change in Gerrit is available as a git ref. E.g. to get patch set 1
of change 8844 you do:

git fetch git://android.git.kernel.org/project.git refs/changes/44/8844/1

The first two digits are change number mod 100, which happily enough
is just the last two digits of the change number.

> Also, I'm not sure if it's just coincidence, but when I run a command
> like this:

Oh, frell. Something about this command locked up the server today.
I'll have to look into this further. What project, opencore? What
does `git rev-parse origin/master` return to you, a SHA-1 or an error
message?

[Garret]

> Oh, frell.  Something about this command locked up the server today.
> I'll have to look into this further.  What project, opencore?

yes - I'm using

--project=platform/external/opencore

 What
> does `git rev-parse origin/master` return to you, a SHA-1 or an error
> message?

I'm actually using $(git rev-list a6a9a96a4ddadb1ea9..HEAD)

which returns a list of SHA's

[Garret]

Hi Shawn,

Sorry about taking down the server today. I won't try the approve
command anymore until I hear that it's fixed.

Back to my original question, I'm looking for a way to automate the
action from the web page of clicking on the

"Submit Patch Set 1"

button

thanks,
Garret

[Shawn Pearce]

On Mon, Aug 31, 2009 at 15:49, Garret<pic...@pv.com> wrote:
> Sorry about taking down the server today.  I won't try the approve
> command anymore until I hear that it's fixed.

I'm trying to track this down, we're leaking database connection
handles somewhere. *sigh*

> Back to my original question, I'm looking for a way to automate the
> action from the web page of clicking on the
>
> "Submit Patch Set 1"
> button

Push directly into the target branch, gerrit will close all of the
open changes that match. But yea, that's risky, you need to open up
push permission, which means you could push something which hasn't
been approved.

[Luciano Carvalho]

Hi Shawn,

Couldn't we have something like: 

ssh -p <port> <host> gerrit submit <change-id>

It would be very nice for some automation plans we have.

Thanks,

Luciano.

[Shawn Pearce]

On Mon, Aug 31, 2009 at 23:47, Luciano Carvalho<lsca...@gmail.com> wrote:
> Couldn't we have something like:
> ssh -p <port> <host> gerrit submit <change-id>
>
> It would be very nice for some automation plans we have.

Sure.

Except a few minor details:

- Submit on the web UI is actually taking the patch set as an
argument, in addition to the change. This is to prevent race
conditions between deciding "I want to submit this" and someone else
uploading a replacement patch set onto that change. So, like approve,
it probably needs to take a commit rather than a change-id.

- Is a submit successful if the dependencies are not yet submitted?
If the dependencies are not yet submitted a submit on the web just
queues up the change, waiting for them to submit. But here we have a
shell exit code to worry about, should we exit 0 in such a case, or
non-zero?

- Someone needs to code it. That someone isn't likely to be me. :-)

Also, maybe we should consider that submit is actually just a special
case of git push. Currently, if I push a commit into a branch, and
that commit is associated with a change, the change is automatically
updated and marked closed. But if the commit is not associated with a
change, or it is, but the change is not yet approved, the push is
still successful as I have push +1 permission in the project.

What if when push is < +1 we submit by allowing a push to the branch,
but only if all of the commits are approved?

[Brad Larson]

On Sep 1, 9:12 am, Shawn Pearce <s...@google.com> wrote:

This seems reasonable. I think the user should also require merge
permissions. What would happen to a commit with dependencies? Would
all of the dependent changes be merged as well?

[Shawn Pearce]

Oh, of course, I forgot to say that, but yes, the user would need
Submit +1 to take advantage of this, since they are actually
submitting the change by issuing a git push.

>What would happen to a commit with dependencies?  Would
> all of the dependent changes be merged as well?

Yes, they would submit automatically as well, but *only* if they were
also approved and ready for submit. If one or more dependencies were
not approved, then the entire thing would abort and nothing would be
submitted.