Difference between revisions of "Gerrit"

From Dogtag
Jump to: navigation, search
(Merging via GerritHub)
m (Uninstalling Gerrit)
 
(41 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 +
= Overview =
 +
 +
Gerrit is used for code review and [[Continuous Integration]] for the following projects:
 +
 +
* [https://review.gerrithub.io/#/q/project:dogtagpki/pki dogtagpki/pki]
 +
* [https://review.gerrithub.io/#/q/project:dogtagpki/tomcatjss dogtagpki/tomcatjss]
 +
 
= Installation =
 
= Installation =
  
Line 6: Line 13:
  
 
= Configuration =
 
= Configuration =
 +
 +
== Configuring SSH Key ==
  
 
Upload an SSH public key to GerritHub: https://review.gerrithub.io/#/settings/ssh-keys
 
Upload an SSH public key to GerritHub: https://review.gerrithub.io/#/settings/ssh-keys
  
To enable Gerrit in the local PKI source repository, find GerritHub's SSH URL in [https://review.gerrithub.io/#/admin/projects/dogtagpki/pki this page] (right above the '''Description''' box, click '''ssh'''). It should be something like:
+
== Configuring Local Repository ==
 +
 
 +
Gerrit configuration only needs to be done once for each local repository. It is recommended to use an existing local repository (instead of cloning a new one) to avoid repeating Gerrit configuration.
 +
 
 +
To check whether Gerrit has been configured in the current repository:
 +
 
 +
<pre>
 +
$ git remote
 +
gerrit
 +
</pre>
 +
 
 +
To enable Gerrit in the local PKI source repository, find GerritHub URL in [https://review.gerrithub.io/#/admin/projects/dogtagpki/pki this page]. Click '''ssh''' tab right above the '''Description''' box.
 +
 
 +
GerritHub URL for PKI should look like the following:
  
 
  ssh://<username>@review.gerrithub.io:29418/dogtagpki/pki
 
  ssh://<username>@review.gerrithub.io:29418/dogtagpki/pki
Line 20: Line 42:
 
</pre>
 
</pre>
  
To enable Gerrit in the local TomcatJSS source repository, find GerritHub URL in [https://review.gerrithub.io/#/admin/projects/dogtagpki/tomcatjss this page]. It should be something like:
+
To enable Gerrit in the local TomcatJSS source repository, find GerritHub URL in [https://review.gerrithub.io/#/admin/projects/dogtagpki/tomcatjss this page].
 +
 
 +
GerritHub URL for TomcatJSS should look like the following:
  
 
  ssh://<username>@review.gerrithub.io:29418/dogtagpki/tomcatjss
 
  ssh://<username>@review.gerrithub.io:29418/dogtagpki/tomcatjss
Line 30: Line 54:
 
$ git review -s
 
$ git review -s
 
</pre>
 
</pre>
 
'''Note:''' This only needs to be done once as long as the local source repository still exists.
 
  
 
= Submitting a patch for review =
 
= Submitting a patch for review =
Line 46: Line 68:
  
 
Then commit the changes in this branch (or cherry-pick the changes into this branch). This may consists of multiple commits.
 
Then commit the changes in this branch (or cherry-pick the changes into this branch). This may consists of multiple commits.
 +
 +
'''REMINDER:'''  Changes to spec file templates should be separate and can generally not be cherry-picked due to differences between branches.
  
 
Notice that a unique Change-Id will be added to the each commit. DO NOT CHANGE this Change-Id. It is used to track the commit in GerritHub.
 
Notice that a unique Change-Id will be added to the each commit. DO NOT CHANGE this Change-Id. It is used to track the commit in GerritHub.
Line 86: Line 110:
 
== Submitting a patch to a branch other than master ==
 
== Submitting a patch to a branch other than master ==
  
The procedure for submitting a patch to a maintenance branch (for example, DOGTAG_10.4_BRANCH) is the same as in the previous section.  In this case though, you need to append the branch name to the git review command. See the example below:
+
The procedure for submitting a patch to a maintenance branch (e.g. DOGTAG_10_5_BRANCH) is basically the same as in the previous section.  In this case though, you need to append the branch name to the git review command.
 +
 
 +
=== Prepare a tracking branch ===
 +
 
 +
First, create a tracking branch for the target branch in the local repository:
 +
 
 +
<pre>
 +
$ git checkout -b DOGTAG_10_5_BRANCH origin/DOGTAG_10_5_BRANCH
 +
</pre>
 +
 
 +
If the tracking branch already exists, use the following command to switch to the branch:
 +
 
 +
<pre>
 +
$ git checkout DOGTAG_10_5_BRANCH
 +
</pre>
 +
 
 +
Then pull the latest changes:
  
 
<pre>
 
<pre>
$ git checkout DOGTAG_10.4_BRANCH
 
 
$ git pull
 
$ git pull
$ git checkout -b ticket-<number>
+
</pre>
$ .. make changes and commit them, or cherry-pick changes to backport
+
 
$ git review DOGTAG_10.4_BRANCH
+
=== Pushing the branch to Gerrit ===
 +
 
 +
Check whether the branch exists on Gerrit:
 +
 
 +
<pre>
 +
$ git branch -r
 +
gerrit/DOGTAG_10_5_BRANCH
 +
</pre>
 +
 
 +
If the branch does not exist on Gerrit yet, push it with the following commands:
 +
 
 +
<pre>
 +
$ git push gerrit DOGTAG_10_5_BRANCH
 +
</pre>
 +
 
 +
=== Preparing changes for the branch ===
 +
 
 +
To make changes for the branch, create a new branch based on the target branch:
 +
 
 +
<pre>
 +
$ git checkout -b ticket-<number> DOGTAG_10_5_BRANCH
 +
</pre>
 +
 
 +
It's recommended to use something like '''ticket-<number>''' as the branch name for clarity.
 +
Use this branch to prepare the changes for the target branch.
 +
 
 +
To cherry-pick changes from master, use the commit ID in master:
 +
 
 +
<pre>
 +
$ git log master
 +
$ git cherry-pick <commit ID>
 +
</pre>
 +
 
 +
'''REMINDER:'''  Changes to spec file templates should be separate and can generally not be cherry-picked due to differences between branches.
 +
 
 +
=== Pushing the changes to Gerrit ===
 +
 
 +
The changes in this branch can be submitted with the following command:
 +
 
 +
<pre>
 +
$ git review DOGTAG_10_5_BRANCH
 
</pre>
 
</pre>
  
Line 108: Line 187:
  
 
= Reviewing a patch =
 
= Reviewing a patch =
 
== Retrieving the changes ==
 
 
If necessary (e.g. for testing), the patches being reviewed can be downloaded with the following command:
 
 
<pre>
 
$ git review -d <change number>
 
</pre>
 
  
 
== Online review ==
 
== Online review ==
Line 125: Line 196:
 
* Once you have finished making comments in all the files you want, go to the top level page.  You will see draft:X in the files you have commented on.  Click "Reply" -- You may add a additional comment on the whole update - or just click Post.
 
* Once you have finished making comments in all the files you want, go to the top level page.  You will see draft:X in the files you have commented on.  Click "Reply" -- You may add a additional comment on the whole update - or just click Post.
 
* When posting a comment, you can specify values for three flags: code-review (-2/-1/0/+1/+2), Verified (-1,+1) and Workflow (-1,0,+1).
 
* When posting a comment, you can specify values for three flags: code-review (-2/-1/0/+1/+2), Verified (-1,+1) and Workflow (-1,0,+1).
 +
 +
== Local review ==
 +
 +
If necessary (e.g. for testing), the patches can be downloaded locally with the following command:
 +
 +
<pre>
 +
$ git review -d <Change-Id>
 +
</pre>
  
 
== Review response ==
 
== Review response ==
Line 186: Line 265:
  
 
== Verified ==
 
== Verified ==
 +
 +
The pki-jenkins-bot should generally run automatically and set Verified +1
 +
upon a successful build.
 +
 +
However, on some occasions, pki-jenkins-bot may fail.  To re-run the bot,
 +
perform the following:
 +
 +
    Hit the "Reply..." button and type the following:
 +
   
 +
    recheck
 +
   
 +
    Hit the "Post" button
 +
 +
Legacy method:
  
 
When we get around to it, we'll have a jenkins gate job that will run and
 
When we get around to it, we'll have a jenkins gate job that will run and
Line 201: Line 294:
  
 
== Merging via GerritHub ==
 
== Merging via GerritHub ==
 
+
=== Merging the Patch to the Desired Branch (e. g. - master) ===
 
If you are the reviewer for a patch and you think the patch is ready to be merged,
 
If you are the reviewer for a patch and you think the patch is ready to be merged,
 
you would set code-review +2, workflow +1 and Verified +1.  At that point, the
 
you would set code-review +2, workflow +1 and Verified +1.  At that point, the
Line 213: Line 306:
 
Once the submit button is clicked, the code is merged.
 
Once the submit button is clicked, the code is merged.
  
In future, when we have set up the jenkins jobs, this will be simpler.  The jenkins
+
'''NOTE:''' In future, when we have set up the jenkins jobs, this will be simpler.  The jenkins
 
job kick off once the Workflow +1 flag is set, and will set the value for Verified.
 
job kick off once the Workflow +1 flag is set, and will set the value for Verified.
 
Assuming that passes, the jenkins just will automatically submit the patch and merge the
 
Assuming that passes, the jenkins just will automatically submit the patch and merge the
 
code.
 
code.
  
== Merging via local Git repository ==
+
=== Merging the Patch to a Required Maintenance Branch (e. g. - DOGTAG_10_5_BRANCH) ===
 +
After a patch has been successfully submitted (e. g. - to 'master'), it may also be
 +
required to "cherry-pick" the patch to a maintenance branch (e. g. - DOGTAG_10_5_BRANCH).
 +
 
 +
The easiest way to do this is to click on the Cherry Pick button which
 +
will display something like the following:
 +
 
 +
    Code Review - Cherry Pick Change to Another Branch
 +
   
 +
    '''Cherry Pick to Branch:'''
 +
   
 +
    '''Cherry Pick Commit Message:'''
 +
    <message from master check-in will be displayed>
 +
   
 +
    Cherry Pick Change                        Cancel
 +
 
 +
Provide the desired "Cherry Pick to Branch" name (e. g. - DOGTAG_10_5_BRANCH) and
 +
press the Cherry Pick Change button.
 +
 
 +
This should start a pki-jenkins-bot which will run a test on that branch and
 +
hopefully yield a "Verified +1 pki-jenkins-bot".
 +
 
 +
Provide yourself:
 +
* at least one +2 and no -2 for code review
 +
* +1 for Workflow
 +
 
 +
A submit button should now be present, and once selected should
 +
merge the patch to the requested branch.
 +
 
 +
'''REMINDER:'''  Changes to spec file templates should be separate and can generally not be cherry-picked due to differences between branches.
 +
 
 +
== Merging via local Git repository (deprecated) ==
 +
'''Note: This method is documented here in case it is needed.  At this point, it is required that merges be done through gerrit as described above.'''
  
 
To merge the patches, cherry-pick the changes to the master branch:
 
To merge the patches, cherry-pick the changes to the master branch:
Line 227: Line 352:
 
$ git cherry-pick master..ticket-<number>
 
$ git cherry-pick master..ticket-<number>
 
</pre>
 
</pre>
 +
 +
'''REMINDER:'''  Changes to spec file templates should be separate and can generally not be cherry-picked due to differences between branches.
  
 
Then push the changes to both upstream repository and GerritHub repository:
 
Then push the changes to both upstream repository and GerritHub repository:
Line 237: Line 364:
 
= Synchronizing GerritHub Repository =
 
= Synchronizing GerritHub Repository =
  
Currently GerritHub repository needs to be synchronized manually. This is normally done by pushing the changes twice as shown earlier:
+
In case GerritHub repository gets out of sync, it can be synchronized at any time with the following commands:
  
 
<pre>
 
<pre>
$ git push origin master
+
$ git checkout master
 +
$ git pull
 
$ git push gerrit master
 
$ git push gerrit master
 
</pre>
 
</pre>
  
In case it gets out of sync, GerritHub repository can be synchronized at any time with the following commands:
+
In case a branch (e.g. DOGTAG_10_5_BRANCH) gets out of sync, GerritHub repository can be synchronized at any time with the following commands:
  
 
<pre>
 
<pre>
$ git checkout master
+
# git checkout -b DOGTAG_10_5_BRANCH origin/DOGTAG_10_5_BRANCH
$ git pull
+
# git pull
$ git push gerrit master
+
# git push gerrit DOGTAG_10_5_BRANCH
 
</pre>
 
</pre>
 
In the future this possibly can be automated by installing [https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks post-receive hook].
 
  
 
= Abandoning a patch =
 
= Abandoning a patch =
  
 
If a patch receives a -2 from a reviewer and cannot be resolved, the patch can be abandoned by clicking Abandon.
 
If a patch receives a -2 from a reviewer and cannot be resolved, the patch can be abandoned by clicking Abandon.
 +
 +
= Uninstalling Gerrit =
 +
 +
<pre>
 +
$ git remote remove gerrit
 +
$ mv .git/hooks/commit-msg .git/hooks/commit-msg.gerrit
 +
$ dnf remove git-review
 +
</pre>
  
 
= References =
 
= References =
Line 265: Line 399:
 
* [https://www.mediawiki.org/wiki/Gerrit/git-review git-review]
 
* [https://www.mediawiki.org/wiki/Gerrit/git-review git-review]
 
* [https://www.slideshare.net/StephenKing/using-gerrit-code-review-in-an-open-source-project Using Gerrit Code Review in an Open Source Project]
 
* [https://www.slideshare.net/StephenKing/using-gerrit-code-review-in-an-open-source-project Using Gerrit Code Review in an Open Source Project]
 +
* [https://gerrit-review.googlesource.com/Documentation/rest-api.html Gerrit Code Review - REST API]
 +
* [https://review.openstack.org/Documentation/cmd-review.html gerrit review]
 +
* [[Jenkins CI]]
 +
* [[Gerrit vs GitHub Pull Request]]

Latest revision as of 19:28, 21 September 2018

Overview

Gerrit is used for code review and Continuous Integration for the following projects:

Installation

$ dnf install git-review

Configuration

Configuring SSH Key

Upload an SSH public key to GerritHub: https://review.gerrithub.io/#/settings/ssh-keys

Configuring Local Repository

Gerrit configuration only needs to be done once for each local repository. It is recommended to use an existing local repository (instead of cloning a new one) to avoid repeating Gerrit configuration.

To check whether Gerrit has been configured in the current repository:

$ git remote
gerrit

To enable Gerrit in the local PKI source repository, find GerritHub URL in this page. Click ssh tab right above the Description box.

GerritHub URL for PKI should look like the following:

ssh://<username>@review.gerrithub.io:29418/dogtagpki/pki

Then run the following commands in the PKI source repository:

$ git remote add gerrit <GerritHub URL>
$ git review -s

To enable Gerrit in the local TomcatJSS source repository, find GerritHub URL in this page.

GerritHub URL for TomcatJSS should look like the following:

ssh://<username>@review.gerrithub.io:29418/dogtagpki/tomcatjss

Then run the following commands in the TomcatJSS source repository:

$ git remote add gerrit <GerritHub URL>
$ git review -s

Submitting a patch for review

Submitting initial patch

First, prepare a branch that is easy to identify (e.g. ticket-<number>) based on the latest master branch:

$ git checkout master
$ git pull
$ git checkout -b ticket-<number>

Then commit the changes in this branch (or cherry-pick the changes into this branch). This may consists of multiple commits.

REMINDER: Changes to spec file templates should be separate and can generally not be cherry-picked due to differences between branches.

Notice that a unique Change-Id will be added to the each commit. DO NOT CHANGE this Change-Id. It is used to track the commit in GerritHub.

To submit the changes to GerritHub, execute the following command:

$ git review

This will generate a review in GerritHub, which you can visit by going to the link provided. Make sure to click GitHub sign-in if required. The commit is tracked by the change ID.

If you have multiple commits, multiple reviews will be created and Gerrit will keep track of the dependencies.

You are about to submit multiple commits. This is expected if you are
submitting a commit that is dependent on one or more in-review
commits. Otherwise you should consider squashing your changes into one
commit before submitting.

The outstanding commits are:

...

Do you really want to submit the above commits?
Type 'yes' to confirm, other to cancel: 

However, if the list includes commits that are already pushed to GitHub, cancel the operation and synchronize GerritHub, then return to the branch and resubmit the changes:

$ git checkout master
$ git push gerrit master
$ git checkout ticket-<number>
$ git review

All reviews you submitted or assigned to you can be found at https://review.gerrithub.io/.

Submitting a patch to a branch other than master

The procedure for submitting a patch to a maintenance branch (e.g. DOGTAG_10_5_BRANCH) is basically the same as in the previous section. In this case though, you need to append the branch name to the git review command.

Prepare a tracking branch

First, create a tracking branch for the target branch in the local repository:

$ git checkout -b DOGTAG_10_5_BRANCH origin/DOGTAG_10_5_BRANCH

If the tracking branch already exists, use the following command to switch to the branch:

$ git checkout DOGTAG_10_5_BRANCH

Then pull the latest changes:

$ git pull

Pushing the branch to Gerrit

Check whether the branch exists on Gerrit:

$ git branch -r
gerrit/DOGTAG_10_5_BRANCH

If the branch does not exist on Gerrit yet, push it with the following commands:

$ git push gerrit DOGTAG_10_5_BRANCH

Preparing changes for the branch

To make changes for the branch, create a new branch based on the target branch:

$ git checkout -b ticket-<number> DOGTAG_10_5_BRANCH

It's recommended to use something like ticket-<number> as the branch name for clarity. Use this branch to prepare the changes for the target branch.

To cherry-pick changes from master, use the commit ID in master:

$ git log master
$ git cherry-pick <commit ID>

REMINDER: Changes to spec file templates should be separate and can generally not be cherry-picked due to differences between branches.

Pushing the changes to Gerrit

The changes in this branch can be submitted with the following command:

$ git review DOGTAG_10_5_BRANCH

Revising a patch

To revise a patch that was already submitted for review simply amend the patch and resubmit:

$ git commit -a --amend
$ git review

As long as the Change-Id is not changed, it will update the existing review.

Reviewing a patch

Online review

  • Go to https://review.gerrithub.io/ and click github sign-in.
  • Click the patch you wish to review.
  • You can make comments on specific files, or on the patch as a whole.
  • To make comments on a specific file, click on the file name. You will see a side by side diff of the file. I usually end up putting in comments on the right hand side (the changed file). Click on the line number at/near the place you want to comment. A box should open up. You can type stuff in and click "Save".
  • Once you have finished making comments in all the files you want, go to the top level page. You will see draft:X in the files you have commented on. Click "Reply" -- You may add a additional comment on the whole update - or just click Post.
  • When posting a comment, you can specify values for three flags: code-review (-2/-1/0/+1/+2), Verified (-1,+1) and Workflow (-1,0,+1).

Local review

If necessary (e.g. for testing), the patches can be downloaded locally with the following command:

$ git review -d <Change-Id>

Review response

In gerrit, there is the concept of a group of core-reviewers. These are the ones that determine what code ultimately gets merged into the repo. These reviewers have the power to +2/-2. Everyone else can review the code and signal their approval by providing +1/-1. All the CS developers have been added to the core reviewer group, so you should all see +2/-2.

A change cannot be submitted to merge unless it receives at least one +2. This is independent of however many -1s or +1s a patch has.

-2 is the core reviewer's indication of rejection with prejudice. No patch can be submitted to merge with a -2. If a review gets a -2, the patch submitter must work with the core reviewer to have them remove their -2.

The possible values are:

  • -2 Do not merge this. You're on the wrong path. If you want to merge this, you need to convince me first. Even if you submit another patch for this review. the -2 will remain until I'm satisfied.
  • -1 This patch did not work for me, or this patch needs some additional work.
  • 0 Neutral. I have some comments but have not really had a chance to give it a thorough review. Or maybe I'm commenting on my own patch.
  • +1 Patch looks good to me but I'm not a core reviewer, or - I'm a core reviewer and the patch looks good to me but its not really my area. I want someone else to look at this.
  • +2 Looks good to me (core reviewer). Lets merge this puppy.

Some example flows:

edewata submits a change. msauton tries out a change and determines it works for him. msauton is not a core-reviewer, so he can only provide a +1. This is insufficient to merge the change. cfu reviews the change and makes suggestions of things to fix. She would provide a -1.

edewata make changes as requested by cfu, and submits a new review. Because the new submission uses the same change ID, the new patch will show up in the same review. cfu looks at the changes and approves them by giving them a +2.

In another example, alee submits a review. jmagne looks at it and decides alee has clearly lost his marbles, and rejects the patch with a -2. The patch cannot merge until alee convinces jmagne of the rightness of his approach. alee fails to do so, and abandons the patch.

In another example, edewata submits a simple one-liner change. This change meets the criteria of not requiring a review. He gives himself and +2.

Note that the policy around +2's is collaborative. We could write submit rules that enforce, for instance, that reviewers not be the same as the authors, but I think this is unnecessary. There will be some patches that you can give yourself a +2 and others that you will ask two or more core reviewers to review. As usual, we'll just trust each other and use best judgment.

Workflow

This is a custom field that I added to follow what Openstack does. Basically, this field is an indication that the change is ready to be merged. For some changes, for instance, we might want more than one reviewer In Openstack, we often require more than one core reviewer to approve a change. The second reviewer specifies approval with +2 and +1 Workflow.

The rule is that a change needs a +1 to be merged. A -1 will prevent a merge. In general, the patch author will often set a -1 for workflow to indicate a patch that is still a work in progress. This is useful to share patches between team members.

Verified

The pki-jenkins-bot should generally run automatically and set Verified +1 upon a successful build.

However, on some occasions, pki-jenkins-bot may fail. To re-run the bot, perform the following:

   Hit the "Reply..." button and type the following:
   
   recheck
   
   Hit the "Post" button

Legacy method:

When we get around to it, we'll have a jenkins gate job that will run and at the very least confirm that the build does not break with this change. This will run automatically when workflow is set to +1. Later, we can add CI tests, pylint etc.

The rule is that you need a +1 to merge. If the jenkins job fails, then it will set -1.

Until those jobs are put in place, the developer who sets Workflow: +1 should also set Verified: +1.

Merging a patch

Merging via GerritHub

Merging the Patch to the Desired Branch (e. g. - master)

If you are the reviewer for a patch and you think the patch is ready to be merged, you would set code-review +2, workflow +1 and Verified +1. At that point, the patch will automatically be merged.

Assuming that all the submit conditions are satisfied, a submit button will appear.

  • at least one +2 and no -2 for code review,
  • +1 for Verified
  • +1 for Workflow,

Once the submit button is clicked, the code is merged.

NOTE: In future, when we have set up the jenkins jobs, this will be simpler. The jenkins job kick off once the Workflow +1 flag is set, and will set the value for Verified. Assuming that passes, the jenkins just will automatically submit the patch and merge the code.

Merging the Patch to a Required Maintenance Branch (e. g. - DOGTAG_10_5_BRANCH)

After a patch has been successfully submitted (e. g. - to 'master'), it may also be required to "cherry-pick" the patch to a maintenance branch (e. g. - DOGTAG_10_5_BRANCH).

The easiest way to do this is to click on the Cherry Pick button which will display something like the following:

   Code Review - Cherry Pick Change to Another Branch
   
   Cherry Pick to Branch:
   
   Cherry Pick Commit Message:
   <message from master check-in will be displayed>
   
   Cherry Pick Change                        Cancel

Provide the desired "Cherry Pick to Branch" name (e. g. - DOGTAG_10_5_BRANCH) and press the Cherry Pick Change button.

This should start a pki-jenkins-bot which will run a test on that branch and hopefully yield a "Verified +1 pki-jenkins-bot".

Provide yourself:

  • at least one +2 and no -2 for code review
  • +1 for Workflow

A submit button should now be present, and once selected should merge the patch to the requested branch.

REMINDER: Changes to spec file templates should be separate and can generally not be cherry-picked due to differences between branches.

Merging via local Git repository (deprecated)

Note: This method is documented here in case it is needed. At this point, it is required that merges be done through gerrit as described above.

To merge the patches, cherry-pick the changes to the master branch:

$ git checkout master
$ git pull
$ git cherry-pick master..ticket-<number>

REMINDER: Changes to spec file templates should be separate and can generally not be cherry-picked due to differences between branches.

Then push the changes to both upstream repository and GerritHub repository:

$ git push origin master
$ git push gerrit master

Synchronizing GerritHub Repository

In case GerritHub repository gets out of sync, it can be synchronized at any time with the following commands:

$ git checkout master
$ git pull
$ git push gerrit master

In case a branch (e.g. DOGTAG_10_5_BRANCH) gets out of sync, GerritHub repository can be synchronized at any time with the following commands:

# git checkout -b DOGTAG_10_5_BRANCH origin/DOGTAG_10_5_BRANCH
# git pull
# git push gerrit DOGTAG_10_5_BRANCH 

Abandoning a patch

If a patch receives a -2 from a reviewer and cannot be resolved, the patch can be abandoned by clicking Abandon.

Uninstalling Gerrit

$ git remote remove gerrit
$ mv .git/hooks/commit-msg .git/hooks/commit-msg.gerrit
$ dnf remove git-review

References