Gerrit for IntelliJ: review, fetch and push without leaving the IDE

One plugin covers the review loop, from query to push

Gerrit for IntelliJ is described as an unofficial IntelliJ Platform plugin for Gerrit Code Review, with the aim of letting you review, fetch and push changes without leaving the IDE. That is a wider scope than a notification widget. The feature list covers voting, replying and commenting on files and lines, listing and querying changes, being notified about changes waiting for your review, checking out, cherry-picking and resetting to changes, running IDE inspections on the files a change touches, and opening files or commits in Gitiles.

The push side is equally involved. The push dialog gains a Gerrit section where you set the target branch, topic, reviewers and CC, with account suggestions, and on Gerrit 2.15 or newer you can also set a hashtag, mark the change as WIP or push it privately. You can submit, abandon and star changes, add reviewers, and on Gerrit older than 2.15 publish and delete draft changes.

Several Gerrit accounts are supported, one per project, which matters for organizations that run more than one instance. Overall this is closer to a client for Gerrit than a thin bridge to a web interface, and the cost of that ambition is a plugin that depends on many parts of Gerrit behaving in specific ways.

The push dialog has no extension point, so options are injected at startup

The README explains the integration in terms of IntelliJ Platform mechanics, and one of those mechanics explains a lot. Most of the communication with Gerrit uses the Gerrit REST API. The change list lives in a tool window, implemented in `com.urswolfer.intellij.plugin.gerrit.ui`.

The push dialog is the awkward part. According to the README, the push dialog has no extension point, so the plugin adds its options to Git's push dialog at startup, with the code in `com.urswolfer.intellij.plugin.gerrit.push`. That is a workaround, not an integration API, and it explains why the Gerrit settings are a checkbox called "Push commits to Gerrit by default" that ticks the option in new push dialogs, with each project then keeping your last choice.

Because the REST API does most of the work, the plugin is only as capable as the server it talks to. Older Gerrit versions lack parts of that API, and the plugin compensates where it can: Gerrit 2.15 added the hashtag, WIP and private change options, while draft publishing and deletion only work on Gerrit older than 2.15.

The first run needs an HTTP password, not your account password

Setting up the plugin is a short sequence of IDE actions, and one detail trips up most newcomers. You open Settings, then Version Control, then Gerrit, and add an account with the web URL of your Gerrit, your login and your HTTP password. The HTTP password is a separate credential from your normal login: in the Gerrit web UI it lives under Settings and HTTP Credentials, or under HTTP Password in older versions. A Test button checks the connection.

Once an account exists, the Gerrit tool window lists the changes of the Gerrit projects whose Git repositories are part of your IDE project. With accounts on several instances, you add all of them and pick the one a project talks to with Use for This Project, and a project whose remotes point at exactly one instance picks it by itself.

Cloning is handled too. To clone a project from Gerrit you use Get from VCS and pick Gerrit as the version control, and the README notes that the plugin can clone Gerrit projects with the commit-msg hook installed. That hook is what turns a local commit into a Gerrit change, so it is a meaningful detail rather than a nicety.

Gerrit 2.9 is the floor, and 2.9 and 2.10 need download-commands

The stated requirement is Gerrit 2.9 or newer, because older versions lack parts of the REST API the plugin depends on. That is a hard floor, not a soft preference.

There is a second, older-looking compatibility gap. Gerrit 2.9 and 2.10 only tell the plugin where to fetch a change from when the `download-commands` plugin is installed on the server; newer Gerrit versions do not need it. The Gerrit update procedure offers to install it but does not select it by default, so if you skipped that step you have to run the update again. For an existing or new instance, this installs it:

    java -jar gerrit.war init -d {gerrit-instance} --install-plugin=download-commands

This is a real operational dependency. The plugin client cannot fetch changes from a 2.9 or 2.10 server unless an administrator has enabled that server-side module, and the error surfaces only when you click a change and see "Cannot fetch changes". The same section also flags an SSL edge case: an SSLException with a bad_record_mac alert means the Gerrit instance or the proxy in front of it accepts only SSLv3, and the fix is to enable TLS on the server side.

Listing every Gerrit change makes diffs and checkouts fail

The default scope is deliberately narrow. The change list shows only changes of the Git repositories in your IDE project, and the troubleshooting notes explain that an empty list usually means the repositories are not registered under Settings and Version Control, or that none of their remotes point at the host of your Gerrit account. When Gerrit is cloned from a different host than its web UI, you set the Clone base URL of the account, or you add a remote named like the Gerrit project with the Gerrit web URL as its URL.

Turning on "List all Gerrit changes (instead of changes from the currently open project only)" widens the list, and that is where the sharp edges are. You can vote on and submit those changes, but showing files and a diff, checking out and cherry-picking all fetch the change into the local clone of its project, so you get the error "No repository found for Gerrit project" until you clone that project and add it to your IDE project. Reviewing a change with no local clone at all is tracked separately as issue #76.

The same wide listing produces a second failure, a 400 response reading "too many terms in query", and the documented fix for that one is to enable the same setting. The behaviour is inverted between the two errors, which tells you the wide list trades one kind of breakage for another.

Cloning from the plugin breaks on some authentication methods

Cloning straight from the plugin does not work with every authentication method. When the clone fails to authenticate or never finishes, the README offers two routes: use the SSH clone URL in the clone dialog, which the Gerrit web UI shows in the project settings, or clone with the Git plugin and add the Gerrit account afterwards. Background for the issue is discussed in a linked Gerrit mailing list topic on repository discussion.

Authentication for the plugin itself is HTTP based, and the plugin documentation shows how to read credentials for a hosted instance. In the Gerrit web UI you open Settings, then HTTP Credentials, then Obtain password, and the text shown contains a line such as:

    gerrit-review.googlesource.com,FALSE,/,TRUE,12345678,o,git-username.gmail.com=password-until-end-of-line

The login is the part before the equals sign and the password is everything after it, and that string has to be pasted into the plugin account settings rather than the password you normally type into the web form.

One performance note sits alongside these instructions: file lists and diffs come from Git, so the plugin fetches the change from Gerrit. Running `git gc` locally and `gerrit gc` on the server, which means asking your Gerrit administrator, usually makes loading faster.

Apache-2.0 for the code, a release per IDE generation

The plugin is released under the Apache-2.0 licence, with the licence text in the LICENSE file at the top of the repository. That is a permissive licence with no copyleft obligation on code that links to the plugin, though the repository also carries contribution and review documents in CONTRIBUTING.md, REVIEW.md, AGENTS.md and CLAUDE.md.

Release naming follows the IDE generation rather than a plain semantic version. The three most recent tags are v2.1.0-203, v2.2.0-203 and v2.3.0-203, published on 2026-10-07, 2026-10-09 and 2026-10-16, and the 203 suffix corresponds to the IntelliJ Platform 2020.3 baseline the README requires. The default branch of the repository is named intellij2020.3 for the same reason. The last push was on 2026-10-16.

That makes upgrade cost predictable in one respect and costly in another. Predictable, because the plugin is published on the JetBrains Marketplace and the README recommends installing from there, which means the IDE can notify you of updates. Costly, because a plugin built against one platform generation will not load on an older IDE, and the README states the requirement as IntelliJ Platform 2020.3 or newer, covering IntelliJ IDEA and its CE edition, RubyMine, WebStorm, PhpStorm, PyCharm and its CE edition, AppCode, Android Studio, DataGrip, CLion, GoLand, Rider and MPS.

Editorial conclusion

Adopt Gerrit for IntelliJ if your team runs Gerrit and your IDE is built on the IntelliJ Platform 2020.3 or newer, and if your Gerrit administrator can enable the download-commands plugin on 2.9 and 2.10 instances. Skip it if your Gerrit predates 2.9, or if you need review features outside the plugin's Gerrit coverage. Before rolling it out, confirm that the account page offers an HTTP password, that each repository has a remote pointing at your Gerrit host, and that the release tag you install matches your IDE build.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. uwolfer/gerrit-intellij-plugin on GitHub