Re: How to setup git-review

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


--[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]--

* 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)


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

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

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


Andrew J Grimberg
Systems Administrator
The Linux Foundation

Join to automatically receive all group messages.