Altering a Gerrit change (git-review workflow)

February 25, 2022 1 By addshore

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.

1) Rebase

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).

2) Checkout

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 698261,3

git-review will fetch this change, and point a branch to the commit, using the format review/<AUTHOR>/<CHANGE-ID>

3) Change

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 --no-edit option.

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.

4) Push

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)

Visualization created with
  1. A commit already exists on Gerrit that is currently up for review
  2. Clicking the rebase button will rebase this commit on top of the HEAD of the branch
  3. Downloading the change using git review -d will fetch the commit, and checkout a nammed branch with a HEAD at that commit
  4. Making a change and ammending the commit, will create a new commit locally, and on the same nammed branch
  5. 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”

Git aliases

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

You can read more about my git aliases in a previous post.