Gerrit/Advanced usage



This page describes the workflow for how MediaWiki core and extensions developers will use Git, git-review, and Gerrit.

The diagram on the right is an accurate description of what our Git workflow looks like. (Transcription is welcome!)

To understand our workflow, see below. For a quick summary, see Git/TLDR.

Easier submission of code
Get an account!

In the old workflow, developers had to send their patch through Bugzilla or email it, then have someone with proper access rights commit it. Extensions developers were prevented from committing to MediaWiki core.

With Git, everyone commits in their local repository. Then everyone is allowed to submit their code for review to Gerrit. There is no more distinction between core and extensions access rights. Since code does not automatically make it into the WMF repository, there's no danger of bad commits unless someone merges irresponsibly. Thus, for many of the Git repositories hosted by the WMF, only a small group of people needs the access rights to merge (apply) the code. See "Who can review?".

This workflow has proven successful for the WMF operation team. That model is also known as "gated trunk" - code needs review before merge - and will be the default model for WMF hosted git repository. Extensions can optionally choose to adopt a straight push model in which code is reviewed post-commit. This is much more like the Subversion model in use before 2012.

If you are wondering who is going to review your code, jump straight to "Who can review?"

Better branching
Git supports branching and merging far better than Subversion did. We are encouraging people to use branches a lot.

With git-review, you can group branches as a "topic" to help with keeping feature development straight. We aim to encourage people to name branches appropriately. If you are fixing bug n, make a "bug n" branch! Look in Gerrit at the top of changesets to see examples. git-review should detect the "bug XXX" in your commit summary and automatically create a topic branch for you.


 * Tags vs branches: branches are for forking, to maintain a separate feature branch. This is like traditional branching.  Tags are more lightweight, designed to point to an individual commit.  You can delete a tag, but they are not mutable.  Designed for tagging releases.  "As of this commit, this was exactly release 1.2.3" -- useful if you aim to tell people to check out specific versions.

Gerrit and Git deal with merge conflicts pretty well. In cases of merge conflicts, the code reviewer gets a notice from gerrit that the merge couldn't go through, and the final merge step fails, but all the code review work will be untouched. To fix the issue, you will have to manually rebase your branch on top of the master branch and resubmit your change.

Getting set up
If you are on Windows, follow labsconsole:Help:Git.

Install & configure Git
Install Git on your computer.
 * Linux: see http://evgeny-goldin.com/wiki/Git#Linux
 * Windows: users can download msysgit (http://code.google.com/p/msysgit/) which includes a version of git and some nifty "Git Bash" tools that act like a basic UNIX shell.
 * Select the "OpenSSH" option in the installer to use ssh-agent.exe. It can instead be configured to work with plink/pageant as may be convenient (provided it doesn't cause any problems).
 * It may also be useful to install TortoiseGit as a complimentary, shell-integrated, GUI but code can only be pushed with the "git review" command via the command line or Git Bash.
 * Mac OSX:
 * Using MacPorts: 'port install git-core'. For using SVN bidirectional bridge, 'port install git-core +svn'
 * FreeBSD:
 * Using pkg_add: pkg_add -rv git

Then do to check that you have a name and email address configured; if you don't, tell Git your username and e-mail address so gerrit can attach it to your accounts:

Get the right permissions
To clone our code repository properly, so as to easily submit a patch back to us, you need a login. We manage this via a unified LDAP login shared between Gerrit and Labsconsole. Get a login!

Log in to https://labsconsole.wikimedia.org/, verify that you can log in, then log in at https://gerrit.wikimedia.org/ with the same username and password. Click Settings, go to SSH Public Keys, and paste in your public key (usually  on Linux) so our git repository will recognize you. (We aim to fix this soon by simply pulling the key from LDAP.)

If you have a few different email addresses or SSH keys, go into Gerrit's settings and add them to your account.


 * Teacher: give the user a login using these instructions.

Clone the repository
Now, you need to clone the code repository in question that you want to make a change on. For a list of all projects in Gerrit, please see the project list in Gerrit, or get a plain-text list with (replace  with your gerrit username):

(or just ssh review gerrit ls-projects if you set up an SSH shortcut)

Create or move to the directory on your machine that you do your development in. If you're making one,  is a good name.

If you want to clone the whole repository:
 * Go have a sip of coffee while you wait for a minute :)

If you want to clone an extension or any other part of the repository (Example: clone an extension named FooBar):

Once cloned, get commit notes which will nicely indicate the old SVN version numbers.

Prepare to work with gerrit
In order to properly work with gerrit, you need to have a pre-commit hook that adds a "change id" to your commit summary. That unique ID will let Gerrit track your commit. Since Git commit identification is based upon a sha1 of the commit id, whenever you amend a commit, the sha1 will change and gerrit would lost track of it!



Using a "gerrit" remote consistently
Before starting with  you should double-check how   refers to repositories. When you clone a repository, by default git gives the remote repository the nickname  (unless you override this with -o gerrit as the sample commands on this page do), thus most git how-tos on the web use "origin". But the  tool prefers to use a remote called. If you're pulling code from gerrit.wikimedia.org then "origin" and "gerrit" are equivalent, yet if you fetch or pull from one but log/show/commit to the other you'll get different results!

Here's how to fix it:


 * Double check the git remotes (nicknames) available:

If it shows something like origin	ssh://username@gerrit.wikimedia.org:29418/mediawiki/core.git (fetch) origin	ssh://username@gerrit.wikimedia.org:29418/mediawiki/core.git (push) then follow these steps.


 * Rename "origin" to "gerrit":

If you already try, the above won't work since you will probably have "gerrit" remote already. So just remove origin:

In order for "git fetch" and "git pull" to show a helpful
 * Change the tracking branch for "git pull":

Your branch is behind 'gerrit/master' by 63 commits, and can be fast-forwarded.

, you need to tell your local branch (for example "master") to track "gerrit/master" instead of "origin/master":

After this you don't need "origin" anymore and you can safely use shortcuts like "git pull" to update your working copy.

Unfortunately you must perform these steps for every project checked out, i.e. core and extensions.

After changes the configuration should look like:
 * Checking if everything is OK:

Linux
Install git-review, a tool to simplify working with Gerrit repositories so you don't have to remember some pretty confusing commands.

Debian
Users of Debian or related distros (e.g., Ubuntu, Mint) can do

Note:  Do not install git-review via apt. It looks like it works, but doesn't.

If you do not have easy_install set up, try

Then run:

in your cloned copy to setup to work with Gerrit. It will probably ask you for your commit username. Then it will automatically install the pre-commit hook.

OpenSUSE
Install (YaST) the, then

FreeBSD
You can directly install git-review through ports.

Windows

 * Install pip using these instructions :
 * Download and install the latest easy installer for Windows: the .exe at the bottom of http://pypi.python.org/pypi/setuptools (make sure it is the right version for your Python; possibly upgrade Python first)
 * Download and uncompress the latest pip version from here: http://pypi.python.org/pypi/pip#downloads (make sure it is the right version for your Python; possibly upgrade Python first)
 * Go to the uncompressed pip directory and run python setup.py install.
 * Add your c:\Python2x\Scripts to the system path (replacing "X" with the actual python version). Different directories are delimited only by a ";", so do not add whitespace.
 * Run pip install git-review
 * Create git-review.bat in some PATH-accessible directory containing the following line (replacing "X" with the actual python version):
 * Make sure you can connect to gerrit properly via SSH.
 * Start Git Bash.
 * Get ssh-agent running if not done already via eval `ssh-agent`.
 * Add your key to the agent if not done so already via ssh-add path/to/key. Make sure the key is in OpenSSH format (.ppk keys can be exported to this format in PuTTyGen).
 * Run . It should give a Gerrit welcome message and then abort.
 * In Git Bash, go to the directory of the fresh MediaWiki clone and run git-review -s. This should install a git hook called "commit-msg" under .git/hooks. Check that the file is there. From now on, commits will have a change-id appended to the summary, which Gerrit will need in order to accept any commits for review.
 * If you get "permission denied (publickey)" no matter what, you have two options. The first is the run  from within the repo's .git/hooks directory every time you want to run "git-review" on a repo for the first time. The second is to try patching "c:\Python2x\Scripts\git-review" to make git-review work properly:
 * If using Python 3 or git-review 1.18, use "unicode.replace" instead of "str.replace".

Mac OS X via Terminal
Mac OS X comes with Python (for now) but not the installation programs supported by git and git-review.


 * 1) Open Terminal and change to a directory you're comfortable downloading test Git packages to (such as Downloads or Sites)
 * 2) Download and install the OSX Installer for Git
 * 3) Install pip (Note: Already included in some older versions of Mac OS X):
 * 4) Install git-review:
 * 1) Install git-review:

git review -s
Whichever method you used to install git-review, run to set it up, before you commit your first change for review.

Manual setup
If installing git-review is not feasible for you, you will use an alternate way to communicate with Gerrit.

First, you need to download a pre-commit hook script and place it in the right directory in your cloned copy of the repository. The script is available from https://gerrit.wikimedia.org/r/tools/hooks/commit-msg and must be placed in the repository sub directory .git/hooks/

1) With a browser:

Download the script from the repo using "Save As ..." then browse to wikimedia-git-repos/examples/.git/hooks/</tt>. Voilà!

2) With wget:

Change to the repository directory (for example,

3) With curl:

You also need to ensure the hook is executable. In Linux you do this with:

When ever you commit a change locally, the hook script will generate a unique Change-Id for you.

Next, add an alias to simplify the command to push changes to Gerrit for review. You can do this by executing the following from your repository clone (for example, within ):

(The refs/for/</tt> is Gerrit magic and must not be omitted. However, you may adapt master</tt> to point to the remote branch that you want to commit to. E.g.: When trying to push to the remote branch Foo</tt> use refs/for/Foo</tt>.)

Update master
Make sure that your master branch (the branch created when you initially cloned the repository) is up to date:

Create a branch
First, create a local branch for your new change. Give the branch a short but reasonably descriptive name.

This will create a new branch (BRANCHNAME) from 'master' and check it out for you. This is equivalent to doing

Use a descriptive branch name. If you are working on a bug, include its id, for example "bug/12345" (this will be what git-review sets the commit's topic to anyway).

Usual way
Change the code in the examples directory in some way; have fun! Review the changes you have made by using git status</tt>, it will show all modified files. To prepare submitting file, you should add your change to the index (the staging area between your working copy and your local repositroy), that is done by using the git add</tt> command.

While doing so you can always review the change already added to the staging area by invoking git status</tt> and look at the diff with git diff --cached</tt>.

Once you are happy with the change list, you can add them to your local repository by using git commit</tt>. You will then be prompted with your favorite editor to add descriptive message for this commit. This is what other people will see when you will later push that commit to another repository.

Then check the changes you've made, within the file(s) and within the directory:

You can repeat this step over and over until you have a set of changes that you want to have pushed to the master branch. One of the cool things about git is that when you git commit</tt>, you are committing LOCALLY. This means you can commit as often as you like without potentially screwing things up for another developer on the project, unlike in SVN where you would want to be very careful that the changes you commit would not cause things to break.

Hence the workflow is something like:

One line shortcut
A shortcut is to ask  to directly add everything from your working copy, this is done using the -a</tt> parameter. So as a shortcut for the above workflow, one could use :

Prepare to push your change set to Gerrit
Before your changes can be merged into master, they must undergo review in Gerrit.

But first, it's a good idea to synchronize your change set with any changes that may have occurred in master while you've been working. From within the branch you've been working on, excute the following command:

git pull</tt> will update the code in your local copy of the master branch. Then, git rebase</tt> will temporarily set aside the changes you've made in your branch, apply all of the changes that have happend in master to your working branch, then merge all of the changes you've made back into the branch. Doing this will help avoid future merge conflicts. Plus, it gives you an opportunity to test your changes against the latest code in master.

Once you are satisfied with your change set and you've rebased against master, you are ready to push your code to Gerrit for review.

Push your change set to Gerrit
If you installed, the command to push changes to Gerrit is very simple:

On Windows it should be git-review &mdash;it should call the "git-review.bat" that you created, if it fails check that the directory where it was placed is in the.

If you had to install the hook manually, you can push your changes by doing:

Upon success, you'll get a confirmation and a link to the changeset in Gerrit.

If your commit addresses a bug in Bugzilla, please comment on that bug to note that the commit is in the merge queue, and link to its changeset in Gerrit.

Improving a change
Sometimes, you might need to improve a submitted change. You can fix your own changes as well as changes submitted by someone else, as long as the change hasn't been merged yet.

Make sure you commit or backup any changed files -- git-review could delete uncommitted files in your local snapshot.

Step 1 - retrieve the current patchset code
You can skip this step if you still have your change on the current branch, or if you can get it again using git checkout, as long as you're sure your branch and Gerrit content are the same commit.

If you have git-review, checkout the change like this:

On Windows use git-review -d <CHANGE NUMBER> instead.

If you don't have git-review, checkout the change like this (you can find this line in Gerrit, on the change, in Download -> checkout, ssh):

Step 2 - Amend the commit and push it again to Gerrit
Make changes,  the files as needed, then commit the change (ensuring you are amending the commit):

If you don't want anymore to include some files in the change:

NOTE: DO NOT use the  flag to specify a commit summary: that will override the previous summary and regenerate the Change-Id. Instead, use the editor to change the commit summary if needed, and keep the Change-Id line intact.

Push the change

On Windows use git-review -R instead.


 * The -R is important here. It tells git-review to not rebase your change against master, which clutters diffs between patch set 1 and 2.

Howto - Merging your amend back into your branch
''This section is optional. It's offered as a convenience way to offer your a solution to a common problem. At this stage, your new changeset is already in Gerrit.''

After you have amended your change, you may want to merge it back into your local branch.

You can do this by going to the Gerrit change in question.

Here is an example:

https://gerrit.wikimedia.org/r/#/c/7669/4

Go to the Download section and copy cherry pick.

We will select patch set 4.

Switch back to your branch. You will be in your review branch where you just made your change.

Note: use the branch relevant to your change number.

Paste in the cherry pick and merge any conflicts.

Perform a git add on the modified files.

Do not forget to check your status and run a diff.

You should see there are no differences:

Then commit the changes:

Submitting a change to a branch for review
In this example, we'll merge from   to.

Before you start, look up the git commit hash of the commit that was merged into master. This can be found on the Gerrit change page. Scroll down to the last Patch Set, and to the left of "(gitweb)" is the git commit hash (not to be confused with the Gerrit Change id). Make sure that the commit was indeed merged into the master branch. If it wasn't then wait with submitting the change to a branch until it has been reviewed and merged in master - until then the commit may still be amended (and we wouldn't want to merge the wrong version).

Here it goes, using :

As a result:
 * https://gerrit.wikimedia.org/r/25756 is created for review.
 * shows both the original and the merge changes

Acting on remote branches
By default, your local clone will only have a local master branch set up to track the remote master branch. Tracking means that whenever you fetch objects from the remote repository, git status or git branch will be able to tell you how up-to-date is your local branch, which is very useful. So, whenever you want to regularly act on a remote branch (lets says REMOTE_BRANCH, you want to setup a one locally (REMOTE_BRANCH too to easily remember about it) that track it (with -t).

will give the full details:

Pushing having used automatic setup
From : git-review accepts, as an optional argument, the branch name to interact with. When that argument is not specified, it falls back to look for the defaultbranch</tt> parameter in a .gitreview</tt> file at the root of the repository.

Every branch should have a .gitreview having a correct defaultbranch value. For mediawiki/core.git</tt>, else people will have to use something like:.

Pushing having used manual (Windows) setup
To change where you push to for review having performed a manual setup, run <tt>git config alias.push-for-review "push gerrit HEAD:refs/for/BRANCH_NAME"</tt> to override the local alias, then use <tt>git push-for-review</tt> as per usual.

Committing to non master
To make a change to the 1.17 branch, create a branch and tag, and push both:

Partial revert of previous commit
Can be find in gerrit patch view in small letters next to text Patch Set N. Then push for review normally.

SSH and "permission denied (publickey)"
If you get the error Then you're not logged in to your ssh key right now. Solution: do  to make it prompt you for the passphrase for your key and add it to the active keychain. Then you can check what's in your keychain with. Then try pushing for review again.

The fingerprint of the Gerrit server is

dc:e9:68:7b:99:1b:27:d0:f9:fd:ce:6a:2e:bf:92:e1

so you can say yes when it asks you to add that fingerprint to the known hosts file.

Keep in mind that gerrit listens on port 29418 and if for some reason you forgot to specify port number, you might be hitting "normal" SSH daemon listening on port 22 (this one has RSA key fingerprint b5:e9:dc:b2:dd:6e:70:f7:18:8a:dc:a3:5d:ab:99:4d).

To check whether SSH connectivity and public key authentication work you can use:

"[remote rejected] master -> master" and "failed to push some refs"
If you forget to add <tt>HEAD:refs/for/master</tt> as an alias, you will receive something along the lines of:

This means you tried to commit to branch "master" instead of submitting your changes for review.

Email doesn't match
remote: ERROR: committer email address (email) remote: ERROR: does not match your user account.

There are two possible problems that could cause this error. If the email address that git pops back _is_ the email address you intend to use with Gerrit, then you should add that email address in Gerrit, and make sure you click the confirmation link in the email Gerrit sends you. Then try pushing again.

If, however, git sends back some nonsense email (like one you don't use anymore, or a local mail address like root@localhost), you should do the following:

To do it locally for just that repo, instead do:

Then, try pushing again.

Build failed due to merge conflict
After `git review` jenkins-bot emails 'This change was unable to be automatically merged with the current state of the repository. Please rebase your change and upload a new patchset.' This might mean that server master branch now has merge conflicts with your patch.


 * Make sure your master branch hard-reset to the gerrit's master
 * Checkout for review, rebase, recommit

Working tree is dirty
Note: if upon doing 'git review' you receive a message "Working tree is dirty" try doing 'git add' for the file(s) changed (or created), then 'git commit', and then 'git review'. This was seen on OSX with an older git client.

missing Change-Id in commit message
Note: if upon doing 'git review' you receive a message about 'missing Change-Id', then your /.git/hooks/commit-msg is probably incorrect. it should look something like:

CHANGE_ID_AFTER="Bug|Issue" MSG="$1"

add_ChangeId { clean_message=`sed -e ' /^diff --git a\/.*/{ s/// q               } /^Signed-off-by:/d /^#/d ' "$MSG" | git stripspace` if test -z "$clean_message" then return fi
 * 1) Check for, and add if missing, a unique Change-Id

You will also get a missing Change-ID message when trying to merge some change from git that does not have. It seems that the hook isn't called by cherry-pick, but it is fortunately called by.

In the example below we will be moving trivial change bd7a268e4be2da23ba0b9943c3b0ba1ac88294dc from git master in the mediawiki/core project (it came via SVN trunk) to REL1_19.

Sample session to exhibit this problem:

(...full trivial diff to one file omitted...)

To fix this, use  (don't commit) option to  : git cherry-pick -n bd7a268e4be2da23ba0b9943c3b0ba1ac88294dc git commit -c bd7a268e4be2da23ba0b9943c3b0ba1ac88294dc

Unfortunately, if you want to add the original commit ID to the message (as done by ) you have to add it yourself.

The change above has been submitted as 3c88c61f1b7e36d5d374a42bb0f50783ab5391a4 for  review.

Don't push
If you attempt to do 'git push' after doing 'git commit' you may receive a response 'Everything up-to-date'. You have not pushed to the branch. You have to do 'git review' to move your changes to gerrit, and only from gerrit will the branch be updated. This seems to be a side effect of checking out master as a branch as of February 2012.

In some projects (e.g. test/) it is possible to do 'git push' instead of 'git review' and have the push succeed. It is probably better not to do that, as it confuses those who find your changes later and don't know where they came from.

git review complains about multiple commits
If <tt>git review</tt> asks you if you really want to submit multiple commits, and lists a bunch of unrelated commits from different branches, try this:

git fetch --all git remote update

<tt>git review</tt> doesn't like merge commits
If you merged a development branch, and now want to submit a merge commit to Gerrit, <tt>git review</tt> may not let you. It may ask you for submitting lots of changes from one of the merged branches, or otherwise mange the commit. To avoid this, push the commit directly to Gerrit, bypassing <tt>git review</tt>:

git push gerrit HEAD:refs/for/master

For more information, see the Gerrit documentation.

Unlink bogus dependencies (rebase changes)
Example for https://gerrit.wikimedia.org/r/#change,5154

git fetch --all # To make sure we have latest changes git review -d Ie6e3c9be git rebase -i gerrit/master # Delete the commits you want to get rid of git commit --amend # Add a note git review -f # -f deletes the branch after submit

Maybe also have look at Gerrit/resolve conflict

Create a dependency
If you are about to create a patch that depends on another (unmerged) patch, or if you already submitted a patch but need to fix the dependency (i.e. currently it is based on master and would break if merged without the dependency, or maybe you squashed your change on top of the dependency). Then this is the section you're looking for. If you want to fix the patch to have the right dependency rather than to create a new patch with a dependency, then make sure your working copy is clean (no uncommitted changes).

git fetch --all # Make sure we have latest info from the repository git review -d 1234 # Gerrit change number of the change you want as dependency ("parent")

Now we need to make sure the patch has the correct git-parent. Depending on whether you are creating a new patch or fixing an existing patch, there is two different ways to do this. If you are starting fresh: git checkout -b bug/1234 # Creates a new branch, with the current branch (the dependency) as parent git add someFile.php some/other/file.js git commit # Commit your patch
 * 1) Edit files: make your changes

git log -n5 --decorate --pretty=oneline # Verify that the last 5 entries of the log now start with:
 * 1) * (HEAD, bug/1234) your change
 * 2) * (review/john/700) the dependency
 * 3) * (gerrit/master)

git push gerrit HEAD:refs/for/master # Use this instead of `git review`

If you need to amend your patch to have the correct dependency: git branch # Take note of the review/* branch that was created for this, it has an "*" in front of it git checkout bug/1234 # Check out the local topic branch of your change git rebase review/john/7000 # The branch name of the gerrit change we checked out earlier


 * 1) Resolve conflicts if needed,
 * 2) - use "git status" to see the files that need resolution
 * 3) - after fixing it in your editor, "git add filename" for each of the fixed files

git commit --amend -c HEAD # Re-commit your patch replacing the one with the wrong parent

git log -n5 --decorate --pretty=oneline # Verify that the last 5 entries of the log now start with:
 * 1) * (HEAD, bug/1234) your change
 * 2) * (review/john/700) the dependency
 * 3) * (gerrit/master)

git push gerrit HEAD:refs/for/master # Use this instead of `git review`

The  directly will make sure that the dependency is kept and the other revisions that are already in gerrit will not be re-submitted.

Splitting a commit in smaller one
Mixing out changes is probably not the best to do nowadays :-D You could split the patch by using something like: git-review -d 4381 git rebase 0d3c396^ git cherry-pick -n 0d3c396 You should now have all changes not staged for commit. Create a topic branch and select the chunks you want by to craft a new commit. git checkout -b language_converter git add --patch You will then be asked what to do with each of the chunk. `?` gives you an help menu, `y` stage the chunk, `s` split it in smaller parts, `n` do not stage it. Then `git diff --cached` to review change and as usual `git commit && git-review -f`
 * 1) Move back to parent of patch set 1
 * 1) Apply patch set 1 changes without generating a commit

How we review code
The things we look for in code won't change, but the workflow is different than it was before the Git switch.

Review before merge
It's important to us to have a review-before-merge workflow, for MediaWiki core and also for any extension we deploy. We will also offer that option to any extensions author who wants it for their extension. (The default is to use the current model we've been using with Subversion -- pushed and automatically merged.) For this decision we will defer to whoever is considered the primary author on the extension. See Git/Gerrit project ownership.

The one exception is i18n commits, which will be able to be pushed without review.

Who can review? Gerrit project owners
Who has the ability to do code review?

We use gerrit to manage code review. Anyone can ask for a Gerrit account (Get an account!). Within Gerrit, anyone can comment on commits and signal their criticisms and approvals. Anyone can give a nonbinding "+1" to any commit (this is like "inspection" and "signoff" in the old Subversion code review interface). However, for any given repository ("Gerrit project"), only a small group of people will have the ability to approve code within Gerrit and merge it into the repository. (Within gerrit, this superapproval is a "+2" even though that's a misleading name, because two +1 approvals DO NOT add up to a +2.) These people are "Gerrit project owners".  To learn about becoming a Gerrit project owner, see Git/Gerrit project ownership.

Even within a Gerrit project, we can also specify particular branches that only specific people can pull into.

To make a new Project Owner:
 * Create a group
 * Give it ownership of a Project
 * Anyone in that group can now add more owners via https://gerrit.wikimedia.org/r/#/admin/projects/ (but we prefer to keep that process public via Git/Gerrit project ownership)
 * Click Groups
 * As long as you are a member of the group, you can edit the group
 * example: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki,access

MediaWiki core
We are maintaining a "WMF" branch of mediawiki/core.git. We use submodules for deployed extensions, and can pull from master as regularly as we want for deployments. At the start of the migration to git, the project owners of this branch are going to be the people who have the ability to deploy code to Wikimedia Foundation servers. gerrit will offer a list of the "Gerrit project owners" for this branch, except for the Operations (system administration) group, which is an LDAP group. Every member of the Wikimedia Foundation operations team will also be in the Gerrit project owners group insofar as they have code review rights globally, but in practice will rarely review code. We may add some existing code reviewers to this Gerrit project owners group. Details; you can request to be added.

At the start of the migration, this list of Gerrit project owners for the WMF branch is also the list of Gerrit project owners for the master branch. However, eventually, we will add to the list of Gerrit project owners for master, using as criteria the number and quality of developers' previous commits and code reviews.

Details and procedure for adding and removing people from the Gerrit project owners groups.

MediaWiki has release branches (19 so far) for core, and master (the default branch previously known as "trunk" in SVN). Example: ("heads" is gitweb's term for branches). MediaWiki core and WMF-deployed extensions will be tagging releases just as we did in Subversion, except they'll be Git tags instead of SVN tags. Any other extension will make its own decisions regarding tagging.

MediaWiki extensions that the Wikimedia Foundation deploys
Same procedure as for MediaWiki core, and the same Gerrit project owner groups.

Other MediaWiki extensions
Every extension author can choose between two choices here: the gated-trunk/push-for-review model, and a straight push model. For any given extension, we will honor the wishes of the person/s listed as the main author on the extension's mediawiki.org page.


 * The gated-trunk/push-for-review is the model that we are using for MediaWiki core, as mentioned above. A Gerrit project owners group (plus the above mentioned Gerrit project owners group for MediaWiki core) will be able to "+2" (approve and merge) changes to their extensions.  The extension author(s) will be able to define a Gerrit project owners group and add others to it.


 * The straight push model is similar to how we did things in Subversion; anyone can suggest a change and submit a pull request, and it will automatically be approved and merged.

We could define groups to make this easier for batches of extensions (e.g. SMW developers). Chad will offer your community a choice. Please let Chad what you would like via Git/New repositories.

Other Gerrit projects
Same procedure as for "other MediaWiki extensions" above.

How to comment on, review, and merge code in Gerrit
Anyone can comment on code in Gerrit.

Viewing and commenting on code

 * Make sure you have a https://gerrit.wikimedia.org login (Get an account!). If you don't know, try logging in at https://labsconsole.wikimedia.org; the username and password should be the same.  If you can't, ask in  for someone to help.
 * Log in to Gerrit. If you know the changeset you want to look at (URL will look like https://gerrit.wikimedia.org/r/#change,2713 ), go to that. Otherwise, use the search box and try searching.  There is no fulltext search in Gerrit, but you can search by author ("Owner"), Gerrit project, branch, changesets you've starred, etc.
 * The changeset has a few important fields, links and buttons:
 * Reviewers. 'jenkins-bot' is the autoreviewer that auto-verifies anything that passes the Jenkins tests. If it passes, you see a green checkmark. If it fails, a red X.  A changeset needs a green checkmark before anyone can merge it.
 * Add reviewer (manually ping someone to request their review. It'll show up in their Gerrit stream)
 * Old Version History dropdown menu. This menu will allow you to change what changes you're reviewing. This is helpful if you reviewed a past changeset, and want to make sure your changes were taken into account. Rather than reading through the entire changeset diff'd against the base commit, you can read only the differences between the current changeset and the changeset you reviewed. There's a bonus, too: You can see your comments on the left hand side of the If there was a rebase commit, there will be garbage in the diffs, but you can read things one changeset at a time and it will still be faster.
 * Diff All Unified button:
 * Opens the diff(s) in a new tab. You can double-click on a line and comment on that line, then save a draft comment! Then, click "Up to change" to go back to the changeset.
 * For commits that contain whitespace changes (i.e. indent a block that was changed), it is best to set the diff-preferences appropriately to make it easier to review. When viewing a diff, on top there is a link "Preferences". Then there is two important settings to focus on. "Ignore Whitespace" and "Intraline Difference". The last one (Intraline Difference) is especially useful if a block of code was indented, as this setting will show the added tabs themselves allowing other changes to be recognizable without having to compare every word in your mind (see screenshot).
 * Abandon Change button (you'll see this if you are the creator of this change set. This action removes the change set from the merge queue, but leaves it in Gerrit for archival purposes)
 * Review button:
 * On this page you can leave an overall comment, view inline comments from the diff that are still in draft form and awaiting publication, and signal your thoughts on the commit. You can signal approval with a "+1" and disapproval with a "-1".  These numbers are nonbinding, won't cause merges or rejections, and have no formal effect on the code review.  To publish your draft inline comments plus your comments on the diff as a whole, click Publish.

Formally reviewing and merging or rejecting code
If you are one of the Gerrit project owners, you'll also see:
 * Abandon Change button
 * on the Review page, additional Code Review options to +2 (approve) or -2 (veto) a diff, and a Publish And Submit button (publish your comment and merge diff into the branch, in 1 step)
 * Submit Patch Set 1 button (merge -- only useful if you or someone else has already given a +2 approval to the diff, but not merged it)

And once you've merged something into the example Gerrit project you'll see it in https://gerrit.wikimedia.org/r/gitweb?p=test/mediawiki/extensions/examples.git;a=summary.

If you merge a commit that references a Bugzilla bug, please go to that bug and mark it RESOLVED: FIXED and reference the merge ID.


 * ''Teacher: for this section, add the participant to the project owner group for the  Gerrit project at https://gerrit.wikimedia.org/r/#/admin/groups/17,members . Add the "Member" by email or wiki username.

How to comment on, review, and merge code in Eclipse
As an alternative to Gerrit's web interface, you can also review code from Eclipse using the Mylyn task-management framework. To get started, download and install Eclipse, and then download Mylyn and install it by unzipping it in the base Eclipse folder. When you next launch Eclipse, you'll be prompted to add a task for Mylyn. From there, you'll need to install the connector for Gerrit, specify  as the server URL, and add your username and password.

Your change could not be merged due to a path conflict
If you get the error "Your change could not be merged due to a path conflict" when submitting a change set in Gerrit, you need to resolve the conflict in a manner very similar to how you would in SVN.
 * 1) Make sure your master branch is up to date: <tt>git pull master</tt>
 * 2) Create and switch to a new branch in which to checkout the change set with the conflict: <tt>git checkout -b BRANCHNAME</tt>
 * 3) Checkout the conflicting change set into this branch. You can copy/paste the correct command from the 'Download' section in the Gerrit review. It will look something like this: <tt>git fetch ssh://awjrichards@gerrit.wikimedia.org:29418/mediawiki/extensions/MobileFrontend refs/changes/38/3538/2 && git checkout FETCH_HEAD</tt>
 * 4) Rebase against master (this should give you a conflict warning. this is OK!): <tt>git rebase master</tt>
 * 5) Open the file(s) with the conflict, and resolve them. They will be denoted the same way they are in SVN (with <<<<< >>>>>)
 * 6) Once you have finished resolving the conflicts, you need to git add the file again. For instance: <tt>git add HtmlFormatter.php</tt>
 * 7) Tell the rebase to continue now that the issue is resolved: <tt>git rebase --continue</tt>
 * 8) Push the resolved conflict to Gerrit for review: <tt>git review</tt>
 * 9) Re-review the change set in Gerrit, and then submit the changes to be merged to master.

Your change requires a recursive merge to resolve
If you get the error "Your change requires a recursive merge to resolve", you need to rebase the change set against master.
 * 1) Make sure your master branch is up to date: <tt>git pull origin master</tt>
 * 2) Create and switch to a new branch in which to checkout the change set with the conflict: <tt>git checkout -b BRANCHNAME</tt>
 * 3) Checkout the conflicting change set into this branch. You can copy/paste the correct command from the 'Download' section in the Gerrit review. It will look something like this: <tt>git fetch ssh://awjrichards@gerrit.wikimedia.org:29418/mediawiki/extensions/MobileFrontend refs/changes/14/3414/3 && git checkout FETCH_HEAD</tt>
 * 4) Rebase against master: <tt>git rebase master</tt>
 * 5) Push the change to Gerrit for review: <tt>git review</tt>
 * 6) Re-review the change set in Gerrit, and then submit the changes to be merged to master.

How to create a repository ("Gerrit project")
See "Request a new Git repository". There's a form to fill out. It should get processed very quickly (within a couple of days).