Gerrit/Advanced usage

The basic instructions to set up and operate with Git and Gerrit are described at the Tutorial (see also its shortest version).

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 parameter in a .gitreview file at the root of the repository.

Every branch should have a .gitreview having a correct defaultbranch value. For mediawiki/core.git, 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 git config alias.push-for-review "push gerrit HEAD:refs/for/BRANCH_NAME" to override the local alias, then use git push-for-review 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 HEAD:refs/for/master 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 git review 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

git review doesn't like merge commits
If you merged a development branch, and now want to submit a merge commit to Gerrit, 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 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
Explained in detail at Gerrit/split_a_submitted_change.

Viewing and commenting on code
The basic functionality is explained in the Git and Gerrit tutorial.

Some extra bits:


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

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
Answered at Gerrit/resolve conflict.

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: git pull origin master</tt>
 * 2) Create and switch to a new branch in which to checkout the change set with the conflict: 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: 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: git rebase master</tt>
 * 5) Push the change to Gerrit for review: 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).