Date
1 - 4 of 4
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?
toggle quoted message
Show quoted text
What is the issue here exactly? Anas On Feb 18, 2016, at 14:05, Andre Guedes <andre.guedes(a)intel.com> wrote: |
|
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?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,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]-- After all the issues folks have been having because of forge author I'veIt worked for us before in many other projects, why is thisI'm not a gerrit expert but from I could understand, this is related to the 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 |
|