Gerrit/Navigation

Gerrit's interface can be difficult to navigate for those new to the tool. The following documentation can help newcomers learn how to navigate Gerrit.

Browsing projects
To view all projects in gerrit, go to Projects > List.

Clicking a project name in that list doesn't give you much useful information, but then you can go to Project > Branches and click the gitweb link for the "master" branch. In gitweb then click the " | tree" link at the top of the list of commits to actually see WTF is in the project. Clicking the "blob" or "raw" link next to a file name will finally show you some code.

The core MediaWiki source code is in project "mediawiki/core", browse away. In general you want to view the HEAD or master branch. If you want to look at the code for the version of MediaWiki or an extension deployed on some wiki, visit that wiki's Special:Version page and look for a corresponding branch or commit.

Search
The search bar is powerful, but requires keywords. The list of these keywords can be found here.

If you enter the e-mail address of a Gerrit participant, you'll see a list of his or her activity.

Code inspection
Usually the underlying code can be found through a "gitweb" or "tree" link, either of which will take you to the Gitweb interface. These links aren't prominently displayed, though. You can find links to gitweb on every change, next to the "Patch Set" fields. You can also access gitweb directly for each project by URL: https://gerrit.wikimedia.org/r/gitweb?p=.git

Reports

 * Updated daily
 * Open changesets by owner
 * Changesets by status
 * Oldest open changesets


 * Source
 * https://github.com/mzmcbride/gerrit-reports


 * Resources
 * Gerrit API: https://gerrit.wikimedia.org/r/Documentation/rest-api.html
 * 45090 – some useful notes in the comments here
 * valhallasw's bot: https://github.com/valhallasw/gerrit-reviewer-bot
 * XSSI wtf


 * Proposals
 * Merged changesets attached to unresolved bugs
 * Bugzilla API: God help me

Gerrit queries
You can run queries against gerrit from the command line. You connect over ssh to execute commands of the form  on the gerrit host.

Commits lists
You can use  to get a list of commits based on several parameters, see documentation; search operators are the same as in the web interface, with some differences and more sugar. It requires developer access.

This will give a list of unreviewed commits:

To show only the count of unreviewed commits, append.

For a list of commits to all MediaWiki repos which have been, or need to be, reviewed by a user (Brion in this example):

it excludes the L10n-bot which sometimes alters the results.

You can define a "review" shortcut in your ssh configuration so that you don't have to enter the full  each time, see Git/Workflow

Counts by user
To get more lists/counts, you can use a simple for loop and grep in a bash script, like this:

In the example we generate some code commits and code review stats for the "mediawiki" group members and other top contributors according to Ohloh (excluding self-merges which are by definition not CR and also most likely minor commits); the output is something like this.

System messages
If you need to ask documentation or other info about a system message (e.g. for Support), it's not that easy to find the correct person. Gerrit and gitweb are useless to this purpose, but here's what you can do:

Look who introduced or modified the message in core: go to your checkout of the code and do, for instance:

To find the previous committer:

With an extension you have to do the same on its i18n template and restrict to the first result (English); if you don't know what extension or what file to check, you'll have to  or   the whole directory (git-blame'ing all the repositories at once is not trivially possible, you'd need to use a script or some   magic to walk through the directories and set the git path).

Now, at last, you have the hash for the change and you can look for it on gerrit or, if it's too old/not in git review, you can use  to get contact info.

Otherwise, a safe bet might be the most (recently) active dev of the extension: go to its repository and get a list of the authors with most commits and their email addresses (@users.mediawiki.org are fake addresses):

Of course you can as well file a bug on bugzilla (if there's the correct component), or on the talk page of the extension or of its maintainer (if the wiki is up to date) and just wait...