Topics

How to setup git-review


Andre Guedes <andre.guedes@...>
 

Hi all,

I was having some trouble to submit a change to Gerrit which depends on
someone else's change. If I use the 'git push' command as described in [1],
I get the following error:

remote: ERROR: In commit <commit id>
remote: ERROR: author email address <someone(a)mail.com>
remote: ERROR: does not match your user account.
remote: ERROR:
remote: ERROR: The following addresses are currently registered:
remote: ERROR: <your email>
remote: ERROR:
remote: ERROR: To register an email address, please visit:
remote: ERROR: https://gerrit.zephyrproject.org/r/#/settings/contact

Talking to Andrew Grimberg from Linux Foundation, he recommended using
git-review and it worked around the issue.

Here are the instructions I followed to setup git-review:

$ cat > .gitreview
[gerrit]
host=gerrit.zephyrproject.org
port=29418
project=zephyr.git

$ git-review -s

To submit your patch(es) to review:
$ git-review -T

I hope this can save you time in case you run into a similar problem ;)

BTW, Andrew submitted a patch adding the .gitreview file so we don't have
to keep it locally.

Regards,

Andre

[1] https://www.zephyrproject.org/doc/collaboration/code/gerrit.html#gerrit
[2] https://gerrit.zephyrproject.org/r/#/c/390/


Nashif, Anas
 

Thanks for documenting this but I don't think forcing people to use git-review is the right approach. It worked for us before in many other projects, why is this different and why can't I use vanilla git to gerrit interaction?

What is the issue here exactly?

Anas

On Feb 18, 2016, at 14:05, Andre Guedes <andre.guedes(a)intel.com> wrote:

Hi all,

I was having some trouble to submit a change to Gerrit which depends on
someone else's change. If I use the 'git push' command as described in [1],
I get the following error:

remote: ERROR: In commit <commit id>
remote: ERROR: author email address <someone(a)mail.com>
remote: ERROR: does not match your user account.
remote: ERROR:
remote: ERROR: The following addresses are currently registered:
remote: ERROR: <your email>
remote: ERROR:
remote: ERROR: To register an email address, please visit:
remote: ERROR: https://gerrit.zephyrproject.org/r/#/settings/contact

Talking to Andrew Grimberg from Linux Foundation, he recommended using
git-review and it worked around the issue.

Here are the instructions I followed to setup git-review:

$ cat > .gitreview
[gerrit]
host=gerrit.zephyrproject.org
port=29418
project=zephyr.git

$ git-review -s

To submit your patch(es) to review:
$ git-review -T

I hope this can save you time in case you run into a similar problem ;)

BTW, Andrew submitted a patch adding the .gitreview file so we don't have
to keep it locally.

Regards,

Andre

[1] https://www.zephyrproject.org/doc/collaboration/code/gerrit.html#gerrit
[2] https://gerrit.zephyrproject.org/r/#/c/390/


Andre Guedes <andre.guedes@...>
 

Hi Anas,

Quoting Nashif, Anas (2016-02-19 14:07:36)
Thanks for documenting this but I don't think forcing people to use git-review is the right approach.
Yes, I agree.

It worked for us before in many other projects, why is this different and why can't I use vanilla git to gerrit interaction?

What is the issue here exactly?
I'm not a gerrit expert but from I could understand, this is related to the
'forge author' settings from submitter rights. I'm CCing Andrew so he might
add more details about it.

Regards,

Andre


Andrew Grimberg <agrimberg@...>
 

On 02/19/2016 08:37 AM, Andre Guedes wrote:
Hi Anas,

Quoting Nashif, Anas (2016-02-19 14:07:36)
Thanks for documenting this but I don't think forcing people to use git-review is the right approach.
Yes, I agree.
Forcing people to use git-review is not the intent. Using git-review
eases the cognitive burden of working inside the enforced gerrit worfklow.

Tell me, which would you find easier to do / remember?

--[cut with git review]--
git checkout master && git pull && git checkout -b my_topic
# make changes
git commit -asm 'gee whiz feature' && git review
--[/cut with git review]--

vs

--[cut without git review]--
git checkout master && git pull && git checkout -b my_topic
# make changes
git commit -asm 'gee whiz feature' && git rebase master && git push
origin HEAD:refs/for/master/my_topic
--[/cut without git review]--

Or for pulling a remote submission for local review

--[cut with git review]--
git checkout master && git pull && git review -d $submission_number
--[/cut with git review]--

NOTES:
* not supplying a patch number gets the latest if multiple, to specify
an earlier version of a submission use $submission_number,$patch_number

* submission number gets checked out locally to
branch review/<user>/topic_name (or revision number if no topic)

vs

--[cut without git review]--
git checkout master && git pull
git fetch origin refs/changes/$change_id_mod_100/$change_id/$patch_number
git checkout -b local_review_of_$change_id FETCH_HEAD
--[/cut without git review]--

It worked for us before in many other projects, why is this
different and why can't I use vanilla git to gerrit interaction?

What is the issue here exactly?
I'm not a gerrit expert but from I could understand, this is related to the
'forge author' settings from submitter rights. I'm CCing Andrew so he might
add more details about it.
After all the issues folks have been having because of forge author I've
relaxed the restriction some. Registered users may 'Forge Author' now,
but this is honestly non-optimal. People should not be repushing changes
that they did not author. The only time that's really a proper option is
when a committer forces a rebase of a patch via the gerrit UI.

Which brings us to git-review, when using it it will detect if you're
trying to push an entire patch set and ask if you really want to do
that, it should also allow you to indicate that you only want to push
certain patches out of the set (though it's a feature I myself never use
as I usually only work a single patch at a time of a series on a
particular topic)

For those that are trying to figure out what these 'forge author' or
'forge committer' rights that we keep talking about in gerrit are, it
breaks down as follows:

A git commit has an author and a committer. Both pieces are stored in
the metadata and in the case of the author, also partly in the commit
message.

The committer is the one who actually pushes the submission to git. The
author is the one that the commit is attributed to. Gerrit takes this
one step further with the requirement of Signed-off-by lines. If the
Signed-off-by line does not match the author it gets rejected.

Enabling 'forge author' allows someone to submit code where the
signed-off-by line does not match the authorship of the code and
additionally, where the one committing the code does not match the
authorship.

'forge committer' (which was only available to committers during the
initial repository load in) allows anyone with the right to push code
that they did not actually commit to the repo. This is useful primarily
in history imports, but occasionally useful for automated processes
(jenkins) that do automatic version bumping, tagging and branching.

-Andy-

--
Andrew J Grimberg
Systems Administrator
The Linux Foundation