Altering a Gerrit change (git 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-review workflow)

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 I’ll use the “Download” button on the right of the change near the changed files.

A dialogue will appear with a bunch of commands that I can copy depending on what I want to do.

As I want to alter the change in place, I’ll use the “Checkout” link.

This will fetch the ref/commit, and then check it out.

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

In order to submit the altered commit back to gerrit, you can just run the following command

git push origin HEAD:refs/for/master

The response of the push will let you know what has happened, and you can find the URL back to the change here.

A third patchset now exists on the change on Gerrit.

Overview

The whole process looks like something like this.

Visualization created with https://git-school.github.io/
  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. Fetching the commit will bring that commit on to your local machine, where you can now check it out
  4. Making a change and ammending the commit, will create a new commit locally
  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
alias.p=!f() { git push origin HEAD:refs/for/master; }; f

And you can level these up to provide you with a little more flexibility

alias.amm=commit -a --amend
alias.amn=commit -a --amend --no-edit
alias.main=!git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@'
alias.p=!f() { git push origin HEAD:refs/for/$(git main)%ready; }; f
alias.pd=!f() { git push origin HEAD:refs/for/$(git main)%wip; }; fCode language: JavaScript (javascript)

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