We present here the git-review utility for command line interaction with https://gerrit.libreoffice.org.
Note that currently another tool can be used, though git-review eases interaction with your local repository and gerrit.
- 1 Installation
- 2 Check your Installation
- 3 Configuration
- 4 Test
- 5 Workflow
- 5.1 Don't actually perform any commands that have direct effects. Print the results instead.
- 5.2 Submit first gerrit patch
- 5.3 Submit subsequent patch for the same change
- 5.4 Supply a review topic
- 5.5 Submit a branch for review and then remove the local branch
- 5.6 Skip the automatic "git rebase -i" step
- 5.7 Download change 4711 from gerrit for review in a new local branch
- 5.8 Cherry pick a change to current branch
- 6 Work on a temporary branch
- 7 Further reading
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
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):
git review -l
should produce something like that:
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 brach 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.
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.
For actual development of git-review how to add new features to the tool see Development/GitReview/Hacking.