Jump to navigation Jump to search

This is the central place to document troubleshooting any problems with Git, Gerrit and git-review.

git clone[edit]

fatal: The remote end hung up unexpectedly[edit]

See for some ideas, and debug the problem by setting the GIT_TRACE=1 environment variable.


git-review complains about problems encountered installing commit-msg hook[edit]

If you encounter this error when trying to push changes using git-review, you are not working with a repository that was cloned via ssh. You must clone repositories using ssh, not http or https, to successfully push changes using git-review.

git-review complains about "missing Change-id in commit message"[edit]

If you forgot to run git review -s, "remote" will complain about "missing Change-id in commit message".

But it will also suggest a commit message with a Change-Id: INNNXXXNNN... line.


  • Copy that line starting with "Change-Id", run git commit --amend, and paste the Change-Id line under your commit message in the text editor that opens up.
  • Or it will suggest a hook fix:
    gitdir=$(git rev-parse --git-dir); scp -p -P 29418 ${gitdir}/hooks/

You should be able to use either method (but the hook didn't work for me), then repeat git review -R and it should complete.

git-review complains "You have more than one commit that you are about to submit"[edit]

If git review displays a warning about multiple commits, followed by a list of other people's commits that have already been merged, perform the following workaround:

  1. Respond "no" to abort git-review.
  2. Run git fetch --all or git remote update (Both commands do exactly the same thing, they fetch objects from all remote repositories set. So just pick the command you remember easily and forget about the other one.)
  3. Rerun git-review

This will ensure git-review has an up-to-date view of the remote master.

Git remote update.png


This was fixed in 2012 but the bug returned. Wikimedia projects suffer from this disproportionately because defaultrebase=0 is set on most Wikimedia projects, and the bug only triggers when rebasing is disabled (using either that setting or the -R flag).

git-review complains "Cannot query patchset information"[edit]

git-review does not work correctly if git generates non-English output. You will see an error like this:

$ git review -d 62474
Cannot query patchset information
The following command failed with exit code 255
    "ssh -x -p None gerrit query --format=JSON --current-patch-set change:62474"
Bad port ' None'

This is due to a bug in git-review.

To work around this on a Linux system, either apply the patch from the bug report above, or set up an alias that forces git to use English output. To do so, put this into your bashrc or similar setup file:

alias git="LANG=C git"

git-review complains "Could not parse json query response: u'Verified'"[edit]

git-review version 1.18 has been reported to have issues when trying to review a change from Gerrit. You will see an error like this:

$ git review -d 76352
Could not parse json query response: u'Verified'

This seams to be due to a bug in git-review version 1.18 since version 1.12 and version 1.21 work correct.

To work around this on a Linux system, use another version like version 1.12 on Fedora or version 1.12, version 1.21 on Ubuntu (by downgrading or removing version 1.18 and installing the suitable rpm). Version 1.22 under fedora works also.

git-review complains "ConfigParser.NoSectionError: No section: 'updates'"[edit]

If this happens (phab:T57732, fixed in newer git-review versions):

$ git review -s
Traceback (most recent call last):
  File "/usr/local/bin/git-review", line 1196, in <module>
  File "/usr/local/bin/git-review", line 1108, in main
    needs_update = latest_is_newer()
  File "/usr/local/bin/git-review", line 179, in latest_is_newer
    if not configParser.getboolean("updates", "check"):
  File "/usr/lib/python2.7/", line 368, in getboolean
    v = self.get(section, option)
  File "/usr/lib/python2.7/", line 607, in get
    raise NoSectionError(section)
ConfigParser.NoSectionError: No section: 'updates'

Adding something like this to ".gitreview" fixes the problem:


git-review doesn't like merge commits[edit]

If you merged a development branch, and now want to submit a merge commit to Gerrit, git review may not let you. It may ask you for submitting lots of changes from one of the merged branches, or otherwise mangle the commit. To avoid this, push the commit directly to Gerrit, bypassing git review:

 git push gerrit HEAD:refs/for/master

For more information, see the Gerrit documentation.

git-review complains "Working tree is dirty"[edit]

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 Mac OS X with an older git client.)

git-review complains about a missing Change-Id in the commit message[edit]

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:


# Check for, and add if missing, a unique Change-Id
add_ChangeId() {
        clean_message=`sed -e '
                /^diff --git a\/.*/{
        ' "$MSG" | git stripspace`
        if test -z "$clean_message"

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

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:

Script started on Sun Mar 25 01:51:46 2012
$ git checkout REL1_19
Switched to branch 'REL1_19'
$ git log --pretty=oneline -n 1
9074142447ab0bd06f4e6a7ca7c9d8c70d33d109 * (bug 35449) Removed double call to OutputPage::setRobotPolicy() in
SpecialWatchlist::execute() (the other one is hidden in SpecialPage::setHeaders()) * Special:Watchlist no
longer sets links to feed when the user is anonymous
$ git show bd7a268e4be2da23ba0b9943c3b0ba1ac88294dc
commit bd7a268e4be2da23ba0b9943c3b0ba1ac88294dc
Author: Marcin Cieślak <>
Date:   Wed Mar 14 00:36:11 2012 +0000

    Cosmetic improvements to PostreSQL updater output
    * Don't WARN on sequences already existing
    * Align dots nicely to the rest
diff --git a/includes/installer/PostgresUpdater.php b/includes/installer/PostgresUpdater.php
index d1fc6f7..d4412cb 100644
--- a/includes/installer/PostgresUpdater.php
+++ b/includes/installer/PostgresUpdater.php
@@ -394,7 +394,7 @@ END;
 	protected function renameSequence( $old, $new ) {
 		if ( $this->db->sequenceExists( $new ) ) {
-			$this->output( "WARNING sequence $new already exists\n" );
+			$this->output( "...sequence $new already exists.\n" );

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

$ git cherry-pick -x bd7a268e4be2da23ba0b9943c3b0ba1ac88294dc
[REL1_19 a354acd] Cosmetic improvements to PostreSQL updater output
 Author: Marcin Cieślak <>
 1 files changed, 18 insertions(+), 18 deletions(-)
$ git log HEAD ^FETCH_HEAD
commit a354acd879c3dd840e7be1e3c6d6fc78d696631d
Author: Marcin Cieślak <>
Date:   Wed Mar 14 00:36:11 2012 +0000

    Cosmetic improvements to PostgreSQL updater output
    * Don't WARN on sequences already existing
    * Align dots nicely to the rest
    (cherry picked from commit bd7a268e4be2da23ba0b9943c3b0ba1ac88294dc)
$ git push gerrit HEAD:refs/for/REL1_19/PostgreSQL
Counting objects: 9, done.
Delta compression using up to 8 threads.
Compressing objects:  20% (1/5)   
Compressing objects:  40% (2/5)   
Compressing objects:  60% (3/5)   
Compressing objects:  80% (4/5)   
Compressing objects: 100% (5/5)   
Compressing objects: 100% (5/5), done.
Writing objects:  20% (1/5)   
Writing objects:  40% (2/5)   
Writing objects:  60% (3/5)   
Writing objects:  80% (4/5)   
Writing objects: 100% (5/5)   
Writing objects: 100% (5/5), 750 bytes, done.
Total 5 (delta 4), reused 0 (delta 0)
remote: Resolving deltas:   0% (0/4)   
remote: Resolving deltas:   0% (0/4)
remote: ERROR: missing Change-Id in commit message
remote: Suggestion for commit message:
remote: Cosmetic improvements to PostgreSQL updater output
remote: * Don't WARN on sequences already existing
remote: * Align dots nicely to the rest
remote: (cherry picked from commit bd7a268e4be2da23ba0b9943c3b0ba1ac88294dc)
remote: Change-Id: Ia354acd879c3dd840e7be1e3c6d6fc78d696631d
To ssh://saper@review:29418/mediawiki/core.git
 ! [remote rejected] HEAD -> refs/for/REL1_19/PostgreSQL (missing Change-Id in commit message)
error: failed to push some refs to 'ssh://saper@review:29418/mediawiki/core.git'

Script done on Sun Mar 25 01:54:08 2012

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

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 git cherry-pick -x) you have to add it yourself.

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


Gerrit complains that "Your change could not be merged due to a path conflict"[edit]

You have to rebase your change in order to be able to merge it.

For the impatient:

git checkout master
git pull
git-review -d <change #>
git rebase origin/master
git status
<edit "both modified" files in status report>
git add <files>
git rebase --continue
git review

Full explanation[edit]

Gerrit does not magically resolve conflicts :)

So you have submitted a change and was approved. But by the time it gets reviewed other commits have altered the main repository which now cause a conflict. Gerrit is unable to automatically merge your change into the repository, you will have to fix it and resubmit the change.

The example below is based on a real use case : change 2514 using the operations/puppet repository

First fetch the change using git-review and its -d option :

(production)$ git-review -d 2514
Downloading refs/changes/14/2514/1 from gerrit into review/hashar/ignore_pyc
Switched to branch 'review/hashar/ignore_pyc'

hashar is the user name, ignore_pyc the topic name he gave. Notice how git-review automatically placed you to the branch.

You now have to rebase on top of the main branch. The change on gerrit shows the branch, just add "gerrit/" in front. For this change in the operations/puppet repo, the main branch is "production", so rebase on gerrit/production; for other repos it's usually origin/master.

(review/hashar/ignore_pyc)$ git rebase gerrit/production

First, rewinding head to replay your work on top of it...
Applying: pyc files are now ignored
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging .gitignore
CONFLICT (content): Merge conflict in .gitignore
Failed to merge in the changes.
Patch failed at 0001 pyc files are now ignored
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To check out the original branch and stop rebasing run "git rebase --abort".
(no branch)$

The key in the above output is the line starting with CONFLICT. It tells you the filename that git couldn't cleanly rebase, usually because your patch alters it and changes in the main branch have also altered it. Running git status confirms it:

(no branch)$ git status
# Not currently on any branch.
# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#	both modified:      .gitignore
(no branch)$ 

Edit the conflicting file (in this case .gitignore). This will have <<<<, ==== >>> markers surrounding the conflicting lines, you must clean this up. During the merge conflict git creates,, and files with the three source versions. You can use a three-way merge tool to pick which lines to use; git mergetool wraps the use of a merge tool.

Once you have finished editing, you have to add that modification to have it used during the rebase then continue fixing any conflicting patches:

(no branch)$ git add .gitignore
(no branch)$ git rebase --continue
Applying: pyc files are now ignored

Since there was no more patches to fix, you have been placed back in the review/hashar/ignore_pyc branch. Looking at the log:

$ git log -n5 --decorate --pretty=oneline
* a3631d2 (HEAD, review/hashar/ignore_pyc) pyc files are now ignored (2 seconds ago
* 1b6cd67 (gerrit/production, production) ensure sample config file removed (18 hours ago)

Verify you change looks fine before resubmitting it to gerrit. Just use git show <sha1 of commit>, i.e. git show a3631d2. You can eventually amend it to state you have rebased the change.

Now submit your change back in the repository:

(review/hashar/ignore_pyc)$ git review
remote: Resolving deltas:   0% (0/2)
To ssh://<someuser>

Heading back to Gerrit, the change is a new patchset pending review.

Congratulations on fixing your first rebase / merge conflict!

In Gerrit your change is not merged after receiving a +2[edit]

If someone enters +2 Code Reviewed, it should trigger a series of automated builds and tests. Continuous integration/Workflow describes the flow.

In Gerrit, the "user" jenkins-bot should add a comment

Starting gate-and-submit jobs.

Follow the link to see the progress of the tests for your change that Zuul has submitted to Jenkins.

If you don't see the "Starting gate-and-submit jobs" comment in gerrit, look at It shows everything that Zuul has submitted to Jenkins, and the "Queue length" number on top is the number of events not yet processed. If your job doesn't appear below this on the page below but the queue length is non-zero, it is likely in the queue; Zuul and Jenkins are probably busy and you just have to wait. But if the queue length is 0 and your change doesn't appear, it means it isn't going to happen and you need to resubmit it. Note that new repos have to be manually added to jenkins-bot's list.

If the required tests all pass (note that some are "non-voting"), then jenkins-bot will add a comment "Build succeeded" followed by "Change has been successfully merged into the git repository."

In Gerrit Jenkins gave a -2 so you need to override Jenkins[edit]

First of all, you should more or less never do this. (So far the reason was backporting a change to an old release that had broken tests). If Jenkins has a -2 you generally can't merge the change. What you need to do:

  • Removing the jenkins-bot "Verified" review (click the [x])
  • Review the latest patch set with "Verified +2" in addition to "Code-Review +2" (this is normally reserved for Jenkins, but since we're overriding it we're replacing its score with our own)
  • Click "Publish and Submit"

"Permission denied (publickey)" error[edit]

fatal: Could not read from remote repository.[edit]

If you get the error

 Permission denied (publickey).
 fatal: Could not read from remote repository.
 Please make sure you have the correct access rights and the repository exists.

Then please share the output of the command git remote show origin, run the affected git command with debug logging variables such as GIT_CURL_VERBOSE=1 GIT_TRACE=1, and test if ssh -p 29418 shows Hi username, you have successfully connected over SSH.

fatal: The remote end hung up unexpectedly[edit]

If you get the error

 Permission denied (publickey).
 fatal: The remote end hung up unexpectedly

Then you're not logged in to your ssh key right now. Solution: do ssh-add ~/.ssh/id_rsa 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 ssh-add -l. Then try pushing for review again.

The fingerprint of the Gerrit server is


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, use ssh -p 29418 which should show Hi username, you have successfully connected over SSH.

Your change is not having all tests run[edit]

Not all tests are run for all users. See Continuous integration/Whitelist for more information.


Push using HTTPS (when SSH is not functional)[edit]

Due to a security incident, https push access has been (temporarily?) disabled. The following section may therefore not be applicable.

Push using SSH only (when HTTPS is disabled not functional)[edit]

Add to your local '.gitconfig' following section:

# Use SSH over HTTPS
[url "ssh://"]
    pushInsteadOf =
    pushInsteadOf =

"git commit --amend" complains "you are in the middle of a merge -- cannot amend"[edit]

When after rebasing and merging your

git commit --amend

results in

message: fatal: You are in the middle of a merge -- cannot amend.

apply these steps and reapply your changes

git stash
git reset --hard
git checkout master
git review -d <change number>
git stash pop
git commit -a --amend

If, 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. Check advanced Gerrit usage to see how to fix them.

"Your change requires a recursive merge to resolve"[edit]

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
  2. Create and switch to a new branch in which to checkout the change set with the conflict: git checkout -b BRANCHNAME
  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:// refs/changes/14/3414/3 && git checkout FETCH_HEAD
  4. Rebase against master: git rebase master
  5. Push the change to Gerrit for review: git review
  6. Re-review the change set in Gerrit, and then submit the changes to be merged to master.

"[remote rejected] master -> master" and "failed to push some refs"[edit]

If push to a branch other than refs/for/master, you will receive something along the lines of:

git push
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 709 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas:   0% (0/1)
To ssh://
 ! [remote rejected] master -> master (prohibited by Gerrit)
error: failed to push some refs to 'ssh://'

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

The following is a similar error where git review was trying to push to a non-existing remote branch:

! [remote rejected] T12345 -> T12345 (prohibited by Gerrit)
error: failed to push some refs to 'ssh://'

You can see with git branch what's the branch you're currently using. Try rebasing to push correctly:

git pull --rebase origin master
git review -R

"[remote rejected] HEAD -> refs/publish/master/??? (Cannot merge change to another branch)[edit]

When attempting to cherry-pick a change or merge an entire branch and then submit for review; gerrit will be very confused if you do not explicitly tell it what branch you're modifying. You might get errors like:

 ! [remote rejected] HEAD -> refs/publish/master/mwalker_test (change 59546 closed)


! [remote rejected] HEAD -> refs/publish/master/mwalker_test (no new changes)

In this case you must ensure that your branch's .gitreview file has the correct defaultbranch option (e.g. it should be pointing to the branch you're attempting to modify) or you must manually push the refspec using git push gerrit HEAD:refs/for/<branch>

! [remote rejected] HEAD -> refs/changes/79/550379/2 (cannot add patch set to 550379.)[edit]

This happens if you are not the original author (owner) of a change (in this case 550379). To be able to add a new patch set to a commit you did not author, please request addition to the Trusted-Conttributors group on Gerrit. Every member of this group is able to add you on request.

Committer email address does not match your user account.[edit]

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:

$ git config --global
$ git commit --amend --reset-author

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

$ git config
$ git commit --amend --reset-author

Then, try pushing again.

Build failed due to merge conflict[edit]

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.

$ git checkout master
$ git fetch --all
$ git reset --hard origin/master
  • Checkout for review, rebase, recommit
$ git review -d <patchNumber>
$ git rebase master
# Fix merge conflicts and add them with 'git add'
$ git rebase --continue
$ git review -R

If the error occurs even though you have rebased your patch as above, try making an arbitrary change to your commit message, and then running git review again (related to bug 53895).

"Everything up-to-date" message after git push[edit]

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.

Tagging an extension doesn't work[edit]

If you want to tag your extension, you need to connect to gerrit using ssh, not https. In your .git/config, the remote url should look like this:

[remote "origin"]
       url = ssh://
       fetch = +refs/heads/*:refs/remotes/origin/*

To tag an extension, use git tag followed by git push:

git tag -a v1.4 -m 'my version 1.4'
git push --tags