From The Document Foundation Wiki
Jump to: navigation, search

We present here the git-review utility for command line interaction with

git-review is a program that is widely used for command line interaction with gerrit and was created by OpenStack project.

Note that currently another tool can be used, though git-review eases interaction with your local repository and gerrit.


On most Linux distributions a git-review package should be available that can be installed with the usual package manager. For manual installation on other systems:

Check your Installation

Check if git-review is working

[david@wizball libo (master)]$ git review --help

usage: git review [upload] [OPTIONS] ... [BRANCH]


Check manual page

man git-review


git review --help

should display the manual page.


If you still did not configure ssh host logerrit in ~/.ssh/config, please set it first up as described here.

If you created logerrit remote manually, then you may want to remove it:

git rm remote logerrit

and let git-review recreate it:

git review -s

Attention !!! This command overwrites our own commit-msg hook and replaces it with the vanilla one from gerrit installation.

Our commit hooks are maintained in .git-hooks/ in the core repo and ./g -z and other ./g call make sure that the proper link are in place to use it. That is how we maintain our hooks and propagate changes to it.

So please, run this command (after git review -s):

./g -z


git review -l

should produce something like that:

git review in action


Don't actually perform any commands that have direct effects. Print the results instead.

Adding the --dry-run switch to unfamiliar but critical commands prevents you from having to solve puzzles you didn't want to ;-)

git review --dry-run ...

Submit first gerrit patch

git add <the files you changed>
git commit -m "a commit summary line"
# or omit -m "..." which fires up your $VISUAL editor where you can enter a first line as commit summary,
# optionally followed by one blank line and then more text for a detailed commit message to describe your commit.
git review

The git review command will tell you if more than one commit would be send to gerrit. This usually is unwanted and you probably forgot about other changes you did on the same branch and already submitted to gerrit and afterwards didn't reset your branch with git reset --hard HEAD^ to the state before, removing the last change. Check carefully what you actually want to do in that case. See further down under [#Work on a temporary branch] for how to prevent that.

Submit subsequent patch for the same change

git add <the changed files>
git commit --amend
git review

Supply a review topic

git review -t foo-topic

Submit a branch for review and then remove the local branch

git review -f

Beware, local branch is removed.

Skip the automatic "git rebase -i" step

git review -R

Use this when submitting an amended subsequent patch for an already existing gerrit change.

Download change 4711 from gerrit for review in a new local branch

git review -d 4711

Cherry pick a change to current branch

git review -x 4711

Work on a temporary branch

To prevent several unrelated patches piling up on your local master branch, get in the habit of working on a separate temporary branch, one per change to be submitted. Git-review also helps in that.

A new branch for a new change

# Create the branch in git:
git checkout -b the_branch_name_you_like
# Do your changes.
git add <the changed files>
git commit
git review -f

The -f option tells git-review to finish the branch, meaning to remove it after successfully submitting the commit to gerrit and then switch back to the master branch. (Where you can create a new branch for the next change ...)

Amending a gerrit change

Often it happens that a reviewer tells you to change something in your patch. To do so you'll have to download the current patch version of the change, amend it with the required changes and resubmit the result as a new patch set onto the same gerrit change without creating yet another new gerrit change. Basically this is done by amending the commit, leaving the Change-Id intact, and when submitting the change gerrit will recognize it as a new patch set for the change with the same Change-Id. Git-review also helps you in this.

# Download change number 4711 from gerrit and create a new branch to work on:
git review -d 4711
# Do your changes.
git add <the changed files>
git commit --amend
# Upload to gerrit:
git review -R -f
# where -R does not rebase, and -f finishes the created branch and puts you back where you were before.

If git review -R -f presents you with a list of unrelated changes and asks you "Do you really want to submit the above commits?" then do not answer yes but instead just press enter and then run the command git review -f without the -R switch.

The branch created by the git review -d 4711 command will have the committer ID (and optionally topic, if set, else the change number) in its name so it does not conflict with other local branches. If the branch already exists it will be updated with the latest patch set of this change. The branch is created from the starting point your current branch (e.g. master) is in. The -R switch in the final git review command omits the automatic rebase step, which comes handy in new patch sets for the same gerrit change because then in gerrit a reviewer can see the difference between two patch sets without all other differences of other commits that happened in between, which would be the case without the -R switch. However, if you already did ./g pull -r (or git pull -r) to update your current branch (e.g. master) before downloading the change that may not be possible anymore. The -f switch again finishes the branch, by switching back to the starting point and removing the branch.

Further reading

For actual development of git-review how to add new features to the tool see Development/GitReview/Hacking.