I don’t use git-review for Gerrit interactions. This is primarily because back in 2012/2013 I couldn’t get git-review installed, and someone presented me with an alternative that worked. Years later I realized that this was actually the documented way of pushing changes to Gerrit.
As a little introduction to what this workflow looks, and a comparison with git-review I have created 2 overview posts altering a gerrit change on the Wikimedia gerrit install. I’m not trying to convince you, either way, is better, merely show the similarities/difference and what is happening behind the scenes.
Be sure to take a look at the other post “Altering a Gerrit change (git workflow)“
One prerequisite of this workflow is that you have git-review installed and a
.gitreview file in your repository!
I’ll be taking a change from the middle of last year, rebasing it, making a change, and pushing it back for review. Fundamentally the 2 approaches do the same thing, just one (git-review) requires an external tool.
Firstly I’ll rebase the change by clicking the “Rebase” button in the top right of the UI. (But this step is entirely optional)
This will create a second patchset on the change, automatically rebase on the master branch if possible. (Or it would tell you to rebase locally).
In order to checkout the change you need to grab the numeric change ID from the Gerrit UI (you can always find it in the URL).
Use this change ID with the
-d flag of git-review, which stands for “download.
If you wanted to checkout a specific patchset of a change you can use the format
git-review will fetch this change, and point a branch to the commit, using the format
I can now go ahead and make my change to the commit in my IDE.
The change is quite small and can be seen in the diff below.
Now I need to amend the commit that we fetched from gerrit.
If I want to change to commit message in some way I can do
git commit --all --amend
If there is no need to change the commit message you can also pass the
You’ll notice that we are still in a detached state, but that doesn’t matter too much, as the next step is pushing to gerrit, and once that has happened we don’t need to worry about this commit locally.
You can then just run
git review, with the
-R flag if you want to avoid automatic rebasing of your changes.
A new patchset now exists on the change on Gerrit.
The whole process looks like something like this. (With git-review adding some extra branch names for changes locally)
- A commit already exists on Gerrit that is currently up for review
- Clicking the rebase button will rebase this commit on top of the HEAD of the branch
- Downloading the change using
git review -dwill fetch the commit, and checkout a nammed branch with a HEAD at that commit
- Making a change and ammending the commit, will create a new commit locally, and on the same nammed branch
- You can then push this altered commit back to gerrit for review
If you want to know more about what Gerrit is doing, you can read the docs on the “gritty details”
You can use a couple of git aliases to avoid some of these slightly long commands
alias.amm=commit -a --amend alias.amn=commit -a --amend --no-edit